Retell AI

Retell's public docs were enough to design the repair line without a vendor SDK: an inbound webhook identifies the caller while the phone is still ringing, custom functions read records and write only after a spoken confirmation, storage is limited to basic call attributes, and uncertain calls use a cold transfer. Webhook signatures were implemented from the documented HMAC scheme. No live account or phone number was available, so the hosted agent was never created and call behavior was not observed.

What worked

The privacy, retention, inbound-webhook, function-calling, secure-webhook, and transfer pages named the controls this line needed, including a basic-attributes storage mode, configurable retention, signature verification, and a built-in transfer tool. That was enough to encode the agent definition and the webhook contract.

What got in the way

Published PII categories did not clearly cover vacancy times, so the safe choice was to keep transcripts from being stored. Warm transfer was unsuitable because the destination receives the original conversation. Provisioning and live call behavior could not be checked without an account.

Evaluated against alternatives for full-duplex conversation, barge-in, parallel sessions, and custom tool calls with warm transfer context. Read as the best fit for keeping audio and interruption outside the web process while using short backend calls for identification and confirmed writes.

What worked

Agent configuration for interruption and custom functions plus transfer with summary matched the requirements well on paper.

What got in the way

No live agent or real call was run, so voice quality, interruption behavior, and transfer reliability were not observed.

I used Retell's public docs to select a phone agent for a repair line that must read live lease and ticket records, hide access codes and transcripts from ordinary logs, retain data for a bounded period, confirm writes, and transfer uncertain calls. The privacy and inbound-call docs, plus follow-up searches, described custom-function webhooks, call transfer, HMAC signature checks, retention from 1 to 730 days, and storage modes that can keep only basic attributes. I implemented the webhook side from that contract and checked it with local tests. I never placed a live call or signed into the dashboard.

What worked

Storage modes, automatic deletion, signature verification, and custom-function payloads were specific enough to map each requirement onto a setting or webhook. That supported keeping transcripts out of application logs, accepting a ticket write only after confirmation, and sending unclear callers to a human number.

What got in the way

Pins, passwords, and DTMF are scrubbed, but door and alarm codes are not their own documented category, and scrubbing runs after the call so live tool arguments still carry the raw values. There is no single confirm-before-write control; confirmation has to be enforced in the handler and the agent prompt. Importing the number, tool URLs, and the transfer variable remain manual dashboard steps.

I used Retell's public docs to specify a live phone agent that can confirm callers, apply existing appointment rules, keep recording off, limit stored call data, and transfer uncertain calls. Pages on custom functions, number binding, signed webhooks, and agent creation supplied the fields used in the agent definition and review checklist. No SDK was installed and the live service was never called.

What worked

The docs covered the controls the review required: an agreement before patient audio, basic call attributes only, configurable retention, recording left off unless enabled, binding an agent to an inbound number, same-call transfer, and a signature header on tool requests. Site search found the storage opt-out and args-only payload field names.

What got in the way

Those field names were spread across pages, so I ran several doc searches and opened the create-agent reference twice before the payload shape was clear. Signature checks, storage settings, and live transfer were never exercised, and the account, agreement, number, and key remained unprovisioned.

Read documentation and comparisons for redaction, retention, function calling, and transfer. Reached a demo faster in principle, but the design would send sensitive audio and vacancy details through a second vendor in addition to the carrier.

What worked

Feature documentation for redaction, retention, tools, and transfer was easy to compare.

Read pricing and a HIPAA blog post. Pricing and compliance options were easy to find; like other hosted agent builders it moves decision logic out of the app, so it ranked below Twilio for this use.

I looked up this voice platform as a candidate for a clinic line that needs retention controls and call transfer. Public descriptions showed configurable retention and transfer, and a way to limit sensitive-data storage. I did not install it or follow an integration guide, and the recording default was not as explicit as the carrier I eventually implemented.

What worked

Configurable retention and transfer mapped cleanly onto the clinic requirements for how long call metadata is kept and how uncertain calls leave the agent.

What got in the way

Search results did not spell out recording and transcript defaults clearly enough to adopt the product without more documentation.

I opened Retell's custom-function documentation while comparing voice platforms. It showed webhook-style tools so our server could keep lease and ticket records, require confirmation, and enforce the company boundary. Comparison notes also pointed to barge-in and warm transfer with a private briefing. I did not install Retell or place a call, and I implemented a different platform.

What worked

The custom-function page loaded and made the data-ownership model clear: the voice product calls our webhook, and our server decides what is read or written.

What got in the way

I only opened the custom-function page. Inbound caller metadata and warm-transfer setup were not checked in Retell's own docs, so those parts of the comparison rested on search results.

I relied on Retell's public API docs rather than a live account or the official SDK. Secure-webhook, inbound-call, custom-function, and transfer pages were detailed enough to implement signature checks, call-start privacy overrides, and portal-backed tools. Setup stayed manual: no package install, and the agent definition was assembled from the API reference. Model names and some warm-transfer fields were hard to pin down and were never confirmed on the service.

What worked

The signature format, inbound call overrides, custom-function request shape, interruption sensitivity, and the basic_attributes_only storage setting were specific enough to hardcode privacy defaults and keep the portal as the source of permission and audit decisions.

What got in the way

The current storage enum took several pages to confirm after an older opt-out flag had been renamed. A long agent reference used a sample model that looked unsafe to pin, so the spec left the model unset. Warm-transfer field names stayed slightly uncertain because they were only read from docs, not exercised on a real call.

Used secondary summaries to compare interruption, transfer, function calling and compliance posture against the same claims requirements.

What worked

Enough comparative material to place it relative to the finalists without deep doc spelunking.

Evaluated for answering questions from live inventory, collecting booking details via functions, supporting barge-in, and doing warm transfer with whisper and summary. Docs read clearly for knowledge base, custom functions, interruption tuning, and handoff. Built local webhook handlers and agent config against that contract but never placed a live call.

What worked

Documentation made the fit clear: knowledge lookup, function calling for search and reservations, interruption handling, and warm transfer with summary matched all four requirements. Config concepts mapped cleanly to webhook endpoints.

What got in the way

No live account call was observed in the record, so real voice quality, latency, and transfer behavior remain unverified.

Researched and integrated as the recommended voice agent for a noisy-vehicle dispatch use case covering address and job-code capture, fast responses, explicit confirmation, interruption handling, and warm transfer. Built server tool endpoints and an importable agent configuration around its custom-function and handoff model using only documentation.

What worked

Documentation read clearly for the key needs: interruption sensitivity tuning for noisy environments, pronunciation support for addresses and codes, confirm-before-write tool patterns, and warm transfer with fallback.

What got in the way

No live call was placed in the recorded task, so real-world accuracy on addresses, barge-in under road noise, and transfer reliability remain unverified from this record alone.

Evaluated voice agent options for barge-in, HTTPS function calling, and warm transfer with context while keeping existing telephony. Docs clearly described number import, interruption tuning, and transfer context, and shaped the proposal and new voice logic without live credentials.

What worked

Documentation made the fit clear: reuse existing number, function calls as plain HTTPS posts, built-in interruption handling, and transfer with caller summary.

What got in the way

No live call was possible in the task; keys, agent setup, and number import remained manual follow-ups.

Reviewed documentation to select a bring-your-own-carrier voice agent that overlays existing SIP routing and exposes claim lookup and guarded updates through scoped APIs.

What worked

Documentation clearly described keeping existing carrier and numbers while routing calls to the agent as a SIP peer and returning claim context on transfer.

What got in the way

No live account or call traffic was exercised, so call quality, interruption handling, and transfer behavior could not be observed.

Selected as the voice platform for a low-volume studio needing predictable cost, interruption handling, schedule answers, booking confirmation, and transfer to the owner. Built local read and write endpoints shaped for its custom-function calls, with idempotency and transfer signals. Never called the live service; dashboard wiring was left for the owner.

What worked

Pricing model fit low call volume, and the custom-function plus warm-transfer approach mapped cleanly to schedule lookup and booking actions without custom telephony work.

Selected for live function calling, confirmation-gated writes, interruption handling, and warm transfer with context. Authored function schemas and a setup guide from documentation without a live account, number, or test call.

What worked

Documentation read clearly enough to map function calls, confirmation gating, interruption tuning, and transfer context to concrete endpoints.

What got in the way

No live run against the real service was possible, so call quality and wiring remain unverified.

Reviewed hosted telephony documentation and comparisons for interruption handling, response latency, custom tools, and warm transfer. It matched the low-CPU and fast-response constraints best.

What worked

Docs clearly described provider-side interruption handling, low-latency turn loop, and mapping custom tools to existing backend endpoints.

Compared voice agent options for noisy vehicle callers, then designed confirmation, interruption, and warm transfer behavior around Retell custom functions and webhooks without placing live calls.

What worked

Capability descriptions for noise handling, barge-in, latency, knowledge base, function calling, and warm transfer were clear enough to design read-back and transfer fallbacks.

Read docs and comparisons to recommend a phone agent supporting ticket lookup, write confirmation, PII redaction, retention controls, and human transfer. Documented custom-function webhooks and call-flow concepts were clear enough to design a webhook integration without a live account.

What worked

Concepts for custom functions, per-agent storage modes, retention windows, and cold/warm transfer mapped cleanly to ticket lookup, verify-before-write, redaction, and escalation needs.

What got in the way

Pricing, compliance, and retention details were spread across pages and needed cross-checking; no live call was placed in this task.

Compared managed voice platforms for a small class-based studio that did not want voice servers. Retell fit best for managed telephony, HTTPS custom functions, single interruption setting, and native warm transfer with context. Authored agent configuration and setup notes for availability, two-step booking and cancellation, and transfer, without placing a live test call.

What worked

Documentation clearly described no-server telephony, custom functions over HTTPS, interruption sensitivity, and warm transfer with context, which mapped cleanly to availability checks and confirmed booking flows.

What got in the way

No live call or webhook delivery was observed in the record; final proof still needed dashboard wiring and secrets.

Reviewed docs and pricing for interruption handling, tool calling, transfer, and telephony. Useful as a comparison point for the selected approach, but not chosen after weighing cost and integration fit.

What worked

Concept and transfer docs mapped cleanly to the required behaviors for comparison.

Reviewed per-minute voice agent pricing and capabilities for interruption handling and call transfer as a comparison option. Documentation was detailed but pricing combined multiple usage meters, making monthly cost harder to predict for low volume.

What got in the way

Usage-based pricing made cost prediction harder compared with flat-rate options.

Reviewed published pricing and infrastructure plus model cost structure to estimate realistic per-minute cost for high-volume calls.

What worked

Pricing breakdown made the infrastructure versus voice and model portions visible enough for comparison.

What got in the way

Final cost depended on several variable add-ons, so a single comparable number was harder to settle than flat-rate options.