De voice-AI-datakaart: opnames, transcripten, API's en terugschrijven naar je CRM

Een voice-AI-datakaart is één pagina met alle artefacten die een gesprek oplevert. Per artefact staat erop waar het wordt opgeslagen, hoe lang het bewaard blijft, hoe het het platform verlaat en in welke van je systemen het terechtkomt. Security vraagt erom vóór de ondertekening, en IT en operations gebruiken de kaart om de integratie te plannen.

Deze gids bouwt die kaart voor Retell AI op basis van de documentatie van Retell. Waar de documentatie niets zegt, lees je wat je moet vragen.

Welke data levert één voice-AI-gesprek op?

Een verbonden gesprek op Retell levert zeven soorten data op, allemaal op één call-object dat wordt geïdentificeerd met call_id:

• Opname. WAV-audio, als gemixt bestand met één kanaal en als meerkanaalsbestand met elke partij op een eigen kanaal.
• Transcript. Platte tekst, een lijst met uitingen inclusief tijdstempels, en een versie waarin elke tool call en het resultaat ervan is verwerkt.
• Analyse na het gesprek. Ingebouwde velden (call_summary, user_sentiment, call_successful, in_voicemail) plus aangepaste velden die je zelf definieert als boolean, tekst, getal of selector.
• Logs. Een openbare log van LLM-requests en -responses, plus een retrievallog van de kennisbank als de agent er een gebruikt.
• Variabelen en metadata. Dynamische variabelen die worden meegegeven of tijdens het gesprek worden verzameld, en een vrij in te vullen metadata-object voor je eigen ID's.
• Telefoonnummers. De nummerweergave bij inkomende gesprekken en het gekozen nummer bij uitgaande gesprekken.
• Operationele velden. Tijdstempels, duur, status, reden van verbreking, bestemming van de gespreksoverdracht, latency en kosten.

De meeste hiervan zijn pas beschikbaar nadat het gesprek is afgelopen, en aangepaste analysevelden blijven leeg bij gesprekken die nooit verbonden zijn.

Waar staat elk onderdeel en hoe haal je het eruit?

Alles staat in het gespreksrecord in je Retell-workspace en verlaat het platform via drie uitgangen: webhooks, de API en CSV-exports vanuit het dashboard.

Vier details zijn belangrijk wanneer je dit koppelt:

• List Calls laat transcripten en recording_url weg om responses klein te houden, dus bij een bulk-backfill combineer je het met Get Call per call_id.
• Webhooks krijgen na 10 seconden een time-out en worden maximaal 3 keer opnieuw geprobeerd, dus dedupliceer op call_id.
• Elke webhook bevat een x-retell-signature-header die je verifieert met je API-sleutel, en Retell publiceert een IP-adres voor je allowlist (100.20.5.228).
• CSV-exports maak je in het dashboard aan op basis van de actieve filters en ze worden een week bewaard. List Export Requests (GET /v2/list-export-requests) geeft de status en download-URL van elke export terug.

Hoe lang bewaart Retell gespreksdata, en kun je opslag uitschakelen?

Standaard bewaart Retell gespreksdata voor onbepaalde tijd. Je past dat per agent aan onder Security & fallback settings.

Bewaartermijn. Kies 1, 3, 7, 30, 60, 90, 180, 365 of 730 dagen, of bewaar voor altijd; via de API stel je data_storage_retention_days in. Verlopen data wordt dagelijks en definitief verwijderd, inclusief opnames, transcripten, logs, dynamische variabelen en metadata. Retell bewaart intern wat basale metadata, maar het gesprek verschijnt niet meer in de geschiedenis of in API-responses.

Opslagmodus. Kies een van de drie:

• Everything. Transcripten, opnames en logs worden opgeslagen.
• Everything except PII. Content wordt opgeslagen zonder de PII-categorieën die je selecteert, en de ruwe originelen worden verwijderd.
• Basic Attributes Only. Er worden geen transcripten, opnames of logs opgeslagen, en Get Call geeft het gesprek zonder die gegevens terug.

Als je opslag uitschakelt, bevatten webhooks nog steeds het transcript en de opname, maar de opnamelink verloopt 10 minuten nadat de webhook binnenkomt. Bouw je webhook-receiver voordat je overschakelt.

Met data_storage_setting in Update Call kun je één gesprek strenger instellen, nooit minder streng. Geautoriseerde dashboardgebruikers kunnen de gevoelige data van een gesprek verwijderen of het gesprek wissen, en Delete Call (DELETE /v2/delete-call/{call_id}) doet hetzelfde via de API. Beide zijn onomkeerbaar.

Opname- en log-URL's verlopen standaard niet. Zet je Opt In Secure URLs (opt_in_signed_url) aan, dan wordt elke URL die je opvraagt ondertekend en verloopt die na 24 uur, of na een duur die je zelf instelt van 1 minuut tot 7 dagen.

Wat verwijdert PII-redactie precies?

Onder Everything except PII detecteert Retell na het gesprek de categorieën die je selecteert en vervangt elk voorkomen door een genummerde placeholder zoals [email 1]. De 13 categorieën zijn: naam, adres, e-mail, SSN, paspoort, rijbewijs, creditcard, bankrekening, wachtwoord, pincode, medisch ID, geboortedatum en klantnummer.

Scrubbing gaat verder dan het transcript: de opname (PII-fragmenten worden een piep), openbare logs, dynamische variabelen, metadata, de gesprekssamenvatting en aangepaste analysedata, en argumenten en resultaten van tool calls. DTMF-cijfers worden [PII INFO] zodra er een categorie aanstaat.

Als je phone_number selecteert, wordt het nummer van de klant uit het gespreksrecord zelf verwijderd (from_number bij inkomende, to_number bij uitgaande gesprekken). Laat dit uit als een downstream-systeem op dat nummer matcht.

Sommige velden worden nooit gescrubd, waaronder call_id, agent_id, tijdstempels, status, reden van verbreking, call_successful, user_sentiment, kosten en aangepaste attributen. Wil je die ook laten vallen, gebruik dan Basic Attributes Only of een bewaartermijn.

Toegang is rolgebaseerd. De rol Member ziet alleen gescrubde geschiedenis, terwijl Admins en Developers ruwe transcripten en opnames kunnen bekijken.

Waar wordt de data gehost, en wat moet security vragen?

Volgens de compliancedocumentatie van Retell is Retell HIPAA- en AVG (GDPR)-compliant en SOC 2 Type 1- en Type 2-gecertificeerd, voldoet het aan de AVG door AWS te gebruiken met een AVG-conform Data Processing Addendum, en levert het momenteel geen diensten binnen de Europese Unie. De BAA en DPA (met EU-modelcontractbepalingen) onderteken je zelf zonder extra kosten, en certificaten en rapporten staan in het Compliance Trust Center.

De openbare documentatie vermeldt geen opslagregio per artefact en noemt de onderliggende opslagdienst niet, dus ga daar niet zomaar van uit. Vraag het schriftelijk na bij Retell (support@retellai.com behandelt securityreviews, leveranciersbeoordelingen en lijsten met subverwerkers), en controleer je eigen instellingen:

• Waar wordt gespreksaudio verwerkt, en waar wordt elk artefact uit de tabel opgeslagen?
• Welke subverwerkers komen in aanraking met audio, transcripten en analyses?
• Komen de bewaartermijn en opslagmodus van elke productie-agent overeen met ons beleid?
• Staan beveiligde URL's aan, met een vervaltijd die we accepteren?
• Welke van onze gebruikers hebben de rol Admin of Developer en kunnen ruwe data zien?
• Verifieert onze webhook-receiver handtekeningen en bewaart hij wat we nodig hebben voordat de bewaartermijn het verwijdert?

Voor de contractkant (BAA versus DPA, blokkades rond dataresidentie, inkoopfases) lees je wat enterprise-kopers moeten weten voordat ze voice-AI uitrollen.

Wat komt er in je CRM terecht, en via welk pad?

Dat hangt af van het pad. De native integraties van Retell met Salesforce, HubSpot, Microsoft Dynamics 365, GoHighLevel en Zoho CRM importeren contacten (elke 5 minuten, per augustus 2026), mappen velden uit de analyse na het gesprek op contactvelden, sturen veldwijzigingen terug en loggen elk gesprek als activiteit. Een Salesforce-Task bevat bijvoorbeeld de duur, samenvatting, conversatie-ID, telefoonnummers en reden van verbreking. Uitgaande synchronisatie werkt alleen bestaande records bij, tenzij je Create new contacts in CRM aanzet, en activiteit wordt alleen gelogd voor contacten die uit het gekoppelde CRM zijn geïmporteerd.

Opnames en volledige transcripten komen alleen in het CRM terecht als het pad ze meeneemt, zoals de gesprekslog van de HubSpot Marketplace-app of je eigen webhook-writer dat doet. Voor de werking van trigger tot terugschrijven, zie de CRM-naar-voice-AI-workflow; de integratiedirectory laat zien wat native koppelt.

Hoe vormen het lezen vóór het gesprek en het schrijven na het gesprek één testbare loop?

Een integratie is af wanneer één gesprek vóór de start het juiste record leest, tijdens het gesprek de afspraak inplant en daarna de notitie voor de monteur schrijft, allemaal op hetzelfde record. De Workflow-pagina van de agent in Retell modelleert dat als één graaf. Bij een lijn voor buitendienst:

1. Lezen vóór het gesprek. Een pre-call-functie zoekt in het CRM naar {{user_number}} en mapt het record-ID naar een variabele. Inkomende gesprekken wachten daar maximaal 1 minuut op; uitgaande gesprekken krijgen 5 minuten voordat er wordt gebeld.
2. Inplannen tijdens het gesprek. De agent plant de afspraak in met een agendatool (Cal.com, Calendly of GoHighLevel-agenda's) of met een custom function die de API van je planningssysteem aanroept, dat de X-Retell-Signature-header kan verifiëren. Het boekings-ID gaat in een variabele.
3. Schrijven na het gesprek. Een post-call-functie maakt de notitie aan: tools voor Salesforce, Dynamics 365 en Zoho maken notities aan, Zendesk voegt privénotities toe, en voor al het andere gebruik je een custom function. De functie hergebruikt het record-ID van vóór het gesprek, schrijft {{call_summary}} of een aangepast veld zoals access_instructions, en draait alleen als de boekingsvariabele bestaat. Post-call-functies stoppen na 5 minuten.

Als de lookup mislukt, wordt elke functie die ervan afhankelijk is overgeslagen, zodat er geen notitie zonder record-ID wordt geschreven, en gaat het gesprek gewoon door. Eén beperking voor platformteams: workflowfuncties configureer je alleen in het dashboard en ze maken geen deel uit van de openbare API (per augustus 2026), dus ze komen niet in je infrastructure-as-code terecht.

Test de loop in twee rondes:

• Simulatietests met mocks. Mock elke custom function en agendatool. Een niet-gemockte functie roept het echte endpoint aan en kan een echte boeking aanmaken.
• Eén echt gesprek tegen een sandboxrecord. Voer een testgesprek via web of telefoon en open het in de gespreksgeschiedenis. Pre-call-functies verschijnen onder Before call en post-call-functies onder Call ended, met de verzonden argumenten en de teruggegeven responses. De test is geslaagd als de boeking bestaat, de notitie op hetzelfde record staat en je receiver één call_analyzed-event voor die call_id heeft gelogd.

Voor het bredere pilotplan, zie hoe je een platform voor stemagents evalueert voordat je live gaat. Voor de werking van pre-call- en post-call-functies, zie Retell Workflows.

Zet de kaart aan het werk

Vul de tabel per agent in en voeg de antwoorden van security toe, dan dient één pagina als je review, integratieplan en audittrail. Wil je zien wat Retell uit elk gesprek haalt en hoe dat naar je systemen stroomt? Begin met de analyse na het gesprek van Retell.