The Voice AI Data Map: Recordings, Transcripts, APIs, and CRM Writeback

A voice AI data map is one page that lists every artifact a call creates, where it is stored, how long it is kept, how it leaves the platform, and which of your systems it ends up in. Security asks for it before signing, and IT and operations use it to plan the integration.

This guide builds that map for Retell AI from Retell's documentation. Where the docs are silent, it tells you what to ask.

What data does one voice AI call create?

A connected call on Retell produces seven kinds of data, all on one call object identified by call_id:

• Recording. WAV audio, as a mixed single-channel file and a multi-channel file with each party on its own channel.
• Transcript. Plain text, an utterance list with timestamps, and a version woven with every tool call and its result.
• Post-call analysis. Built-in fields (call_summary, user_sentiment, call_successful, in_voicemail) plus custom fields you define as boolean, text, number or selector.
• Logs. A public log of LLM requests and responses, plus a knowledge base retrieval log if the agent uses one.
• Variables and metadata. Dynamic variables passed in or collected during the call, and a free-form metadata object for your own IDs.
• Phone numbers. The caller ID on inbound calls and the number dialed on outbound calls.
• Operational fields. Timestamps, duration, status, disconnection reason, transfer destination, latency and cost.

Most of these are available only after the call ends, and custom analysis fields stay empty for calls that never connected.

Where does each piece live, and how do you get it out?

Everything lives on the call record in your Retell workspace and leaves through three exits: webhooks, the API and dashboard CSV exports.

Four details matter when you wire this up:

• List Calls omits transcripts and recording_url to keep responses small, so a bulk backfill pairs it with Get Call per call_id.
• Webhooks time out after 10 seconds and retry up to 3 times, so deduplicate on call_id.
• Each webhook carries an x-retell-signature header you verify with your API key, and Retell publishes an IP to allowlist (100.20.5.228).
• CSV exports are created in the dashboard from the active filters and kept for one week. List Export Requests (GET /v2/list-export-requests) returns each export's status and download URL.

How long does Retell keep call data, and can you turn storage off?

By default, Retell keeps call data indefinitely. You change that per agent under Security & fallback settings.

Retention period. Choose 1, 3, 7, 30, 60, 90, 180, 365 or 730 days, or keep forever; through the API, set data_storage_retention_days. Expired data is deleted daily and permanently, covering recordings, transcripts, logs, dynamic variables and metadata. Retell keeps some basic metadata internally, but the call no longer appears in history or API responses.

Storage mode. Pick one of three:

• Everything. Transcripts, recordings and logs are stored.
• Everything except PII. Content is stored with your selected PII categories removed, and the raw originals are deleted.
• Basic Attributes Only. No transcripts, recordings or logs are stored, and Get Call returns the call without them.

If you opt out of storage, webhooks still carry the transcript and recording, but the recording link expires 10 minutes after the webhook arrives. Build your webhook receiver before you switch.

Update Call's data_storage_setting can make a single call stricter, never less strict. Authorized dashboard users can remove a call's sensitive data or delete the call, and Delete Call (DELETE /v2/delete-call/{call_id}) does the same by API. Both are irreversible.

Recording and log URLs do not expire by default. Turn on Opt In Secure URLs (opt_in_signed_url) and each URL you request is signed and expires after 24 hours, or a duration you set from 1 minute to 7 days.

What does PII redaction actually remove?

Under Everything except PII, Retell detects the categories you select after the call and replaces each occurrence with a numbered placeholder such as [email 1]. The 13 categories are person name, address, email, SSN, passport, driver's license, credit card, bank account, password, PIN, medical ID, date of birth and customer account number.

Scrubbing covers more than the transcript: the recording (PII intervals become a beep), public logs, dynamic variables, metadata, the call summary and custom analysis data, and tool call arguments and results. DTMF digits become [PII INFO] whenever any category is on.

Selecting phone_number removes the customer's number from the call record itself (from_number on inbound, to_number on outbound). Leave it off if a downstream system matches on that number.

Some fields are never scrubbed, including call_id, agent_id, timestamps, status, disconnection reason, call_successful, user_sentiment, cost and custom attributes. To drop those too, use Basic Attributes Only or a retention period.

Access is role-based. The Member role sees only scrubbed history, while Admins and Developers can view raw transcripts and recordings.

Where is the data hosted, and what should security ask?

Retell's compliance documentation states that Retell is HIPAA and GDPR compliant and SOC 2 Type 1 and Type 2 certified, that it meets GDPR by using AWS with a GDPR-compliant Data Processing Addendum, and that it does not currently operate services within the European Union. The BAA and DPA (with EU Standard Contractual Clauses) are self-signed at no extra fee, and certificates and reports sit in the Compliance Trust Center.

The public docs do not list a storage region per artifact or name the underlying storage service, so don't assume one. Ask Retell in writing (support@retellai.com handles security reviews, vendor assessments and subprocessor lists), and confirm your own settings:

• Where is call audio processed, and where is each artifact in the table stored?
• Which subprocessors touch audio, transcripts and analysis?
• Does each production agent's retention period and storage mode match our policy?
• Are secure URLs on, with an expiry we accept?
• Which of our users hold Admin or Developer roles and can see raw data?
• Does our webhook receiver verify signatures and keep what we need before retention deletes it?

For the contract side (BAA versus DPA, residency blockers, procurement stages), see what enterprise buyers need to know before deploying voice AI.

What reaches your CRM, and through which path?

It depends on the path. Retell's native integrations with Salesforce, HubSpot, Microsoft Dynamics 365, GoHighLevel and Zoho CRM import contacts (every 5 minutes as of August 2026), map post-call analysis fields onto contact fields, push field changes back, and log each call as an activity. A Salesforce Task, for example, carries the duration, summary, conversation ID, phone numbers and disconnection reason. Outbound sync updates existing records only unless you turn on Create new contacts in CRM, and activity is logged only for contacts imported from the connected CRM.

Recordings and full transcripts reach the CRM only when the path carries them, as the HubSpot Marketplace app's call log or your own webhook writer does. For trigger-to-writeback mechanics, see the CRM-to-voice AI workflow; the integrations directory lists what connects natively.

How do the pre-call read and post-call write form one testable loop?

An integration is finished when one call reads the right record before it starts, books the appointment during it, and writes the technician note after it, all on the same record. Retell's agent Workflow page models that as one graph. On a field service line:

1. Pre-call read. A pre-call function searches the CRM for {{user_number}} and maps the record ID to a variable. Inbound calls wait up to 1 minute for it; outbound calls allow 5 minutes before dialing.
2. In-call booking. The agent books with a calendar tool (Cal.com, Calendly or GoHighLevel calendars) or a custom function calling your scheduling system's API, which can verify the X-Retell-Signature header. The booking ID goes into a variable.
3. Post-call write. A post-call function creates the note: Salesforce, Dynamics 365 and Zoho tools create notes, Zendesk adds private notes, and anything else takes a custom function. It reuses the pre-call record ID, writes {{call_summary}} or a custom field such as access_instructions, and is gated to run only when the booking variable exists. Post-call functions stop at 5 minutes.

If the lookup fails, every function depending on it is skipped, so no note is written without a record ID, and the call still goes ahead. One constraint for platform teams: workflow functions are configured in the dashboard only and are not part of the public API (as of August 2026), so they won't live in your infrastructure-as-code.

Test the loop in two passes:

• Simulation tests with mocks. Mock every custom function and calendar tool. An unmocked function calls its real endpoint and can create a real booking.
• One real call against a sandbox record. Place a web or phone test call and open it in call history. Pre-call functions appear under Before call and post-call functions under Call ended, with the arguments sent and responses returned. Pass only if the booking exists, the note is on the same record, and your receiver logged one call_analyzed event for that call_id.

For the wider pilot plan, see how to evaluate a voice agent platform before going live. For how pre-call and post-call functions work, see Retell Workflows.

Put the map to work

Fill in the table per agent and attach the security answers, and one page serves your review, integration plan and audit trail. To see what Retell extracts from each call and how it flows to your systems, start with Retell's post-call analysis.