Skip to main content
11x sends a POST request to your configured webhook URL after each call is completed and analyzed. The payload contains everything about the call: contact details, duration, transcript, assigned outcomes, extracted variables, and any actions taken by the agent or requested by the contact. The full payload schema is documented in the API Reference tab under Webhooks.

Sample payload

Agent-specific fields

Three fields in the payload are shaped by your agent’s configuration rather than a fixed schema: customInputVariables, callResult.extractedVariables, and callResult.outcomes. The keys and values shown in the sample above are placeholders — expect the sets configured on your agent instead.
  • customInputVariables — the custom variables you submitted when enrolling the contact, echoed back verbatim. The set of keys is whatever your agent’s configuration requires (the same variables the schedule endpoints ask you to include).
  • callResult.extractedVariables — values the agent extracted from the conversation, keyed by the extraction variables configured on your agent.
  • callResult.outcomes — each name is one of the outcome definitions configured on your agent, not a fixed enum. Fetch the configured set with List agent outcomes to map webhook outcomes back to their definitions programmatically.

callResult.followUpMeetingDetails

Present when a meeting was booked during the call; absent entirely when no meeting was booked.

callResult.resultType values

sequence.lifecycleStatus values

Use sequence.lifecycleStatus to determine whether a contact is still actively enrolled.

Delivery and retries

If your endpoint does not answer with a 2xx, times out, or cannot be reached, the webhook is retried up to 8 more times, about 69 hours in all. Every attempt sends the same payload. A webhook is not retried when its URL is refused (malformed, or resolving to a private address) or when your response is too large to read. Switching the webhook off, or removing its URL, stops any retries in progress; a URL you correct during retries is used for the remaining attempts. Delivery is at least once: a request your endpoint processed but did not answer in time is sent again, so the same call can arrive more than once.

Best practices

  • Implement idempotency — key records on callId and let a later delivery for the same call replace the earlier one.
  • Respond quickly — return a 2xx promptly and process the payload asynchronously.
  • Log deliveries — keep webhook request logs for debugging.
  • Monitor failures — set up alerting on webhook processing errors.

Testing your endpoint

Fetch a sample webhook payload for any agent to test your endpoint before going live: