Webhooks
Webhooks push call data to your endpoint in real time so you do not need to poll for updates. Use them to log calls in your CRM, trigger downstream automations, and store transcripts or extracted outcomes for reporting.
Validate webhook authenticity with HMAC signature verification. See webhook security for setup details. To inspect delivery status, payloads, and HTTP responses, use Webhook logs in the Synthflow dashboard.
Webhook types
Synthflow supports two webhook types:
Post-call webhook
When a call completes, Synthflow sends a structured payload to the external_webhook_url you provide in the call request.
Add a webhook URL to the request in order to receive information after the call.
Setting up a Webhook
- Specify the Webhook URL: In your API request body, include the
external_webhook_urlkey with the URL of your webhook receiver. - Test with the webhook: For development and testing purposes, you can use webhook.site to simulate receiving webhook data.
API Request Example
Include the following key-value pair in your API request body:
Webhook Response Example
Upon completion of the call, the webhook URL will receive a response like the following. In this case, the agent has three information extractor actions to get information after the call is completed.
Call Status options
The call object in the webhook response contains a status field which can have various values, each indicating a different state of the phone call. Below is a table explaining these statuses:
End Call Reason options
This end_call_reason parameter provides insight into the reason why a call ended:
When a call ends due to a custom end-call reason, the response also includes a custom_end_call_reason field with the specific condition that triggered the termination (e.g., "Customer is being abusive").
Post-Call Analytics
The analysis object contains automated quality assessments generated after every call. Each field evaluates a specific aspect of the conversation and returns one of the following values:
true: the criterion was metfalse: the criterion was not metpartial: the criterion was partially met (only for fields that support it)not_applicableornull: the criterion does not apply to this call
Every field also has a corresponding _feedback field (e.g. persona_feedback) that provides a short explanation when the result is not true. Feedback is empty when the criterion is fully met or not applicable.
Aggregate Fields
Collected Variables
The collected_variables field contains the collected variables (slots) from your conversation flow. This allows you to access user-provided information programmatically.
The object contains the variable names as keys, with each variable having:
Example:
Only variables with collected: true are included in the response. System variables and variables with collected: false are filtered out.
Inbound webhook
Before an inbound call connects to an agent, Synthflow sends a call_inbound event to your endpoint so you can reroute the call or inject context.
You can intercept, reroute and decline every incoming call with inbound call webhooks.
Set inbound_call_webhook_url on the agent to your receiver endpoint when creating or updating an assistant.
You will receive a JSON payload (event: "call_inbound") within 10 seconds after a call was initiated. Your endpoint will need to respond with an updated call_inbound object to assign an agent to the call or update the metadata.
What to expect
- If your endpoint responds with an empty call_inbound object (e.g.
{}with no agent assignment), the call will be disconnected. - If you return
override_model_idas an empty string (""), the call continues with the agent that received the call (no reroute, no disconnect). - If your endpoint doesn’t respond within timeout, the call is put on hold. Up to 3 more requests will be sent. If all these attempts fail, the call will be rerouted to the
default_agentyou specified. If you did not specify adefault_agent, the call will be disconnected.
Requests
Every inbound call will generate and send a JSON in this format:
Responses
Your endpoint needs to respond with an updated call_inbound object.
FAQ
Is there a maximum post-call webhook payload size on Synthflow's side?
Synthflow does not enforce a fixed maximum payload size for post-call webhooks. In most payload size incidents, the receiving endpoint rejects the request because of its own request body limit.
Can a webhook fail because the payload is too large?
Yes. Your receiving system can return HTTP 413 Payload Too Large when the webhook body exceeds its configured limit. This is common when calls are long, transcripts are large, or many actions are included in one payload.
How do I troubleshoot missing post-call webhooks for large calls?
Start by checking your endpoint logs for HTTP 413 responses. Then increase the accepted request body size in your webhook receiver and any proxy in front of it, such as Cloudflare, API Gateway, Nginx, or your app server. If needed, reduce payload size by disabling transcript storage downstream or trimming what you persist.
How do I debug a missing or failed webhook?
Check your endpoint logs first, including HTTP 413 for oversized payloads. Then open Logs > Webhook logs in the dashboard to see the request Synthflow sent and the response your server returned. See Webhook logs. You can also query deliveries via the webhook logs API.