> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Phone Call Records > Every call your voice agent takes or places is kept as a record — who called, how long, what was said — and you can read them from chat, the CLI, the API, or an MCP client. # Phone Call Records Every phone conversation your voice agent has is kept: the calls it **places** for you, and — once the agent has [its own phone number](/voice#give-an-agent-its-own-phone-number-inbound-calls) — the calls people place **to it**. Each record holds who was on the line, when the call happened, how long it lasted, a short summary, and the full transcript. Inbound calls used to be answered but not kept. If someone called your agent's number, the conversation happened and then vanished. It is now recorded the same way an outbound call is, so a call that comes in at 9pm is still there in the morning. ## What a record contains | Field | What it tells you | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Direction | `inbound` — someone called your agent's number — or `outbound`, a call Erdo placed for you. | | From / To | The two numbers. On an inbound call, **from** is the caller. | | Status and duration | Whether the call completed, and how long it ran. | | Summary | One or two sentences: what the person wanted, and any contact details or booking they left. | | Transcript | The full conversation, as readable lines and as raw data. | | Contact and lead | On an inbound call: the name, email and phone Erdo read out of the conversation, and whether that became a lead. See [An inbound caller becomes a lead](#an-inbound-caller-becomes-a-lead). | ## Ask in chat The simplest way in. Ask for the calls themselves, or for one call's transcript: > "Has anyone called my Sofia number this week?" > "What did the caller say on that last call?" Erdo lists the calls — newest first, with direction, both numbers, duration and a summary — and reads back the full transcript of whichever one you pick. You can narrow to one agent or to inbound calls only just by saying so. ## Your agent asks callers who they are On an **inbound** call the person on the line is a stranger — Erdo has no other way to reach them. So the agent asks, naturally and at most twice, for their name and the best email or phone to follow up on, spells an email back to confirm it, and accepts a "no thanks" gracefully. What they share lands in the transcript and the summary. On an **outbound** call it does the opposite: you already told Erdo who to call, so the agent never asks the recipient for their own contact details. ## An inbound caller becomes a lead Someone who dials your number is a stranger who wants something, which is what a lead is — so every inbound call that arrives with a caller ID is saved as one, whether or not the caller gave a name or an email. The number itself is enough to follow up on, and the carrier verified it, so it is the lead's phone. A name and an email join the row when the caller gave them; the call's summary rides along, so the row says why they rang. The only call that produces no lead is one from a withheld number where the caller stated no way to reach them. Outbound calls are not leads — you already knew who you were calling. The lead carries `source = phone_incoming_call`, which is how you tell callers apart from the leads your landing pages and website widget capture in the same table. Where the row lands is a setting on the phone deployment (**Agents → Deployments → the phone runtime → Save leads**), resolved the same way a widget's is: a dataset you pick, else your organization's leads dataset when you have exactly one, else a "Widget leads" dataset Erdo creates for you (the name is historical — it is the catch-all for leads with nowhere else to go). Untick the setting and calls are still recorded — they just stop producing leads. Someone who calls a second time from the same number is recognised: the call merges into the lead their first call created rather than starting a second row, and anything new they said — an email they didn't give last time — fills in what was blank. Identity is the email address where there is one and the phone number otherwise, so a caller who leaves an email on one call and not on the next can still land as two rows — the same limit a landing page has. Each call record says what happened to its lead, so you never have to guess: the contact Erdo read out of the call, and the outcome — **created** (a new lead), **existing** (merged into a lead already in the table), **disabled** (lead saving is off for this deployment), or **test** (a preview or automated check, never written). A lead is not instant. The contact details are read out of the call after it ends, so the row appears within roughly 15 to 30 minutes of hang-up — the same pass that fills in the summary. ## Read them programmatically The same list-and-read surface is available over the [REST API](/api/overview), the [CLI](/cli), and to MCP clients, so a scheduled automation or an external dashboard can pull calls without going through chat. All of them are scoped to your organization by your credentials. * **List** — `GET /v1/voice/calls` (or a `POST` with a JSON body) returns each call's id, direction, both numbers, status, timing, duration, summary, and the lead it produced, newest first and paginated. Narrow with `agent` (a voice agent's slug) and `direction` (`inbound` or `outbound`). When a response includes `next_cursor`, pass it back as `cursor` to read the next stable page — this avoids skips when a call comes in during a multi-page scan. MCP tool: `erdo_voice_call_list`. * **Read one** — `GET /v1/voice/calls/{call_id}`, using a `call_id` from the list, returns the rendered transcript, the raw transcript, a structured `turns` array with per-turn model latency and token usage, and the same three lead fields the list carries. MCP tool: `erdo_voice_call_get`. The lead a call produced reads the same on every surface. `contact` is the `{first_name, last_name, email, phone}` Erdo read out of the call, `lead_status` is `created` | `existing` | `disabled` | `test`, and `lead_saved_at` is when that outcome was recorded. Two absences mean different things and are worth keeping apart if you are counting: `contact` is `null` while the call has not been read yet and an object with blank fields once it has been read and nobody was reachable, and `lead_status` is an empty string while the lead writer has not reached the call rather than meaning no lead. From the CLI: ```bash theme={null} # The last 25 calls, both directions erdo voice calls list # Just the inbound calls to one agent erdo voice calls list --agent sofia --direction inbound # One call in full, as JSON erdo voice calls get conv_01abc... ``` Website chat widget conversations are a separate surface — they belong to a widget rather than to a phone number. See [Website Concierge](/voice-widget#read-conversations-programmatically) for those. ## Good to know * **Summaries fill in on their own.** A call is summarized shortly after it ends, so a record read moments after hang-up may show a transcript before its summary. * **Records follow the agent, not the person.** An inbound caller is not an Erdo user, so the record belongs to your organization and the agent that answered. * **Retention matches your other conversation data.** Transcripts are visible to your workspace members through Erdo — treat them like any other customer communication.