AI call QA for CloudTalk.
Point CloudTalk's "Call Ended" webhook at CallGuard and every call is pulled, transcribed, scored against your scorecard and matched to the right agent automatically — no code to deploy, no middleware, no manual export. It's our most deeply built-out dialer integration: tolerant field mapping, agent-ID matching, and full call-history backfill for journey scoring.
Point CloudTalk at us. That's the integration.
CloudTalk fires a "Call Ended" (or "Recording Uploaded") webhook when a call finishes. CallGuard validates it, dedupes it, and enqueues the call for processing — waiting a short, tunable delay by default, since the recording is often still processing on CloudTalk's side when the event lands — then pulls the recording via CloudTalk's own API and scores it. No Lambda bridge, no container to run.
Point the webhook at us
Generate a CallGuard API key and add it to CloudTalk's "Call Ended" webhook config, pointed at our ingestion endpoint. Takes a few minutes, no code required.
We fetch the recording automatically
CallGuard waits (60 seconds by default, tunable per account) for CloudTalk to finish processing, then downloads the recording via CloudTalk's API using your API credentials. Calls under 15 seconds — no-answers, voicemails, instant hangups — are dropped automatically.
Transcribed, scored, attributed
Speaker-diarised transcription, scored against your scorecard, and matched to the correct agent by CloudTalk's stable numeric agent ID rather than a fragile name match.
Harden it when you're ready
In Settings, add an HMAC signing secret so CallGuard verifies every webhook genuinely came from CloudTalk, override field mapping if your account's payload differs from the default, and tune the fetch delay to match how long your account actually takes to process a recording.
CloudTalk's calls in. Compliance evidence out.
Webhook-driven, no middleware
CloudTalk's "Call Ended" webhook posts straight to our endpoint. Unlike our AWS Connect adapter, there's no Lambda bridge or container to deploy on your side.
Idempotent by design
A retried webhook delivery is deduplicated on the call's own ID, or a hash of the recording URL when CloudTalk's payload doesn't carry one, so a flaky delivery never double-scores a call.
Stable agent attribution
Calls are matched to your agent roster by CloudTalk's numeric agent ID, not by name-matching — so spelling differences between what CloudTalk's webhook, CloudTalk's roster and your CallGuard account each call the same person never misattribute a call.
Tunable recording-fetch delay
Defaults to 60 seconds after the webhook fires, adjustable per account so it fits how long your CloudTalk account genuinely takes to finish processing a recording.
HMAC-verified webhooks, optional but recommended
Works on API-key auth alone. Add a signing secret in Settings and CallGuard rejects any request that doesn't carry a matching HMAC signature.
Call-history backfill for journeys
CallGuard can pull a customer's full CloudTalk call history by phone number, so a multi-call sale journey is assembled correctly even when an earlier call predates your CloudTalk connection being configured.
Common questions, answered.
Is this a live, mid-call integration like your Twilio or AWS Connect adapters?
No, and we want to be upfront about that. CloudTalk's webhook fires when a call has ended and its recording is ready, not while the call is still live, so a CloudTalk call is transcribed and scored shortly after it finishes, typically within a minute or two, rather than flagged mid-call. If you need breach alerts while the call is still happening, our Twilio and AWS Connect adapters stream audio live; CloudTalk doesn't currently expose a live media stream for us to integrate against.
Do we need to deploy anything on our side?
No. Unlike our AWS Connect integration, which needs a small Lambda bridge, CloudTalk's webhook can point directly at our endpoint. You generate a CallGuard API key, add it to CloudTalk's "Call Ended" webhook config, and you're done. No code to deploy, no infrastructure to run.
How do calls get matched to the right agent?
By CloudTalk's stable numeric agent ID, not by matching names. Dialer webhooks and agent rosters spell the same person differently, for example a webhook sending "Vish" where the roster has "Vish Bhalla" and CallGuard has "Vishall Bhalla", so matching on the ID CloudTalk assigns avoids misattributing a call to the wrong adviser.
What if CloudTalk's webhook payload doesn't match your default field names?
CloudTalk's own webhook documentation doesn't fully specify the "Call Ended" payload shape, so our default field map tries several likely key names for each field (recording URL, agent, customer number, call duration and so on) and takes the first one that matches. If your account sends different keys, you can override the mapping per field in Settings, without waiting on us to ship a fix.
Can you backfill calls from before we connected CloudTalk?
Yes. With your CloudTalk API credentials, CallGuard can pull a customer's call history directly from CloudTalk by phone number and date window. This is what lets a multi-call sale journey be assembled correctly even when an earlier call in that journey happened before your CloudTalk connection was configured.
Is the webhook secured?
Every request needs a valid CallGuard API key. For a stronger check, set a signing secret in your CloudTalk connection and CallGuard will verify an HMAC signature on every webhook, rejecting anything that doesn't match, before it's processed.