Skip to main content
A webhook sends each new task to your system as an HTTPS POST. Use it to open a ticket in Zendesk, create a card in ClickUp, or page a manager, without polling the Customer API. Answering Agent sends one event today, task.created. It fires when the AI creates a task from a conversation or a website form submission.

Set up the webhook

Team owners and admins manage the webhook. Each team has one webhook address.
  1. Go to Settings → Webhooks in the dashboard.
  2. Paste your endpoint address under Endpoint address and save.
  3. Copy the Secret. Your endpoint uses it to check that requests come from Answering Agent.
  4. Click Send test. The page shows whether the test was delivered, and the error when it was not.
The address must:
  • Start with https://.
  • Use a public domain name. IP addresses, localhost, and .local or .internal names are rejected.
  • Leave out a username and password.
To turn the webhook off, clear the address and save. Tasks created while the webhook is off are not sent later.

Check the secret

Every request carries the secret in the X-Answering-Agent-Secret header. Compare it with the secret from Settings → Webhooks and reject any request where it does not match. The header holds the secret itself, not a signature. Answering Agent does not sign or hash the body. Anyone who has the secret can send requests your endpoint accepts, so store it like a password.
JavaScript (Express)

Change the secret

Saving a new address keeps the same secret. To get a new secret, clear the address and save, then enter the address again and save. The page then shows a new secret. Update your endpoint before you send the next test.
Clearing the address turns the webhook off. Tasks created while it is off are never sent, and retries still pending for earlier tasks stop. Answering Agent does not queue them for later.After you save the address again, fetch the tasks you missed with GET /tasks?range=today. If the webhook was off across midnight in your team’s timezone, also fetch range=yesterday. Skip any task your system already has.

The task.created event

Read the task from data. location, task, and caller are legacy fields kept for integrations built before data existed.
string
A stable ID for this event, in the form {source_type}:{source_id}:task.created. Every retry of the same event has the same id. Use it to skip duplicates.
string
task.created, or webhook.test for the test button.
string
When the conversation or form submission came in, as an ISO 8601 UTC timestamp.
integer
Your team ID.
object | null
The task, the same object GET /tasks/{task_id} returns, with its id, status, assignee, category, priority, customer, source conversation or form, and description. It uses the API’s names and IDs. Answering Agent reads the task after any automatic assignment and again for each retry, so data shows the task as it is when that request is sent. null when the dashboard does not show the task.

Legacy fields

location, task, and caller came before data. They keep their original names and values so existing integrations keep working. Read data in new code. The legacy values differ from data in these ways:
  • task.channel uses the stored channel names phone_call, sms, chat_widget, and email. data.conversation.channel uses phone, text, web_chat, and email.
  • task.category is a display label from a separate task category list, such as Retention. data.category is the conversation’s category key, such as cancellation.
  • task.title and task.description come from the first follow-up the AI wrote. data.title and data.description are what the dashboard shows for the task, and they can differ.
  • task.source_type and task.source_id identify the source. data.id is already the API task ID, such as conversation-184532.
object
The phone line the task came from: phone_number_id, name, and phone_number. Each can be null, for example for a form submission that is not tied to a line.
object
object
The customer’s name and phone. Either can be null.

The webhook.test event

Send test posts a short event with the same headers. It has no location, task, caller, or data.
Return a 2xx status so the test counts as delivered.

Delivery and retries

  • Response. Return any 2xx status within 8 seconds. Do the slow work after you respond.
  • Retries. A 5xx, 408, or 429 response, a timeout, or a connection error counts as a failed attempt. Answering Agent retries a failed delivery up to 4 more times, waiting longer between attempts. It ignores a Retry-After header. After the last failed retry, the event is dropped. Use GET /tasks to find tasks your endpoint missed.
  • No retry. Other responses, including 3xx and 4xx, end delivery for that event. Answering Agent does not follow redirects, so point the webhook at the final address.
  • Duplicates. Your endpoint can get the same event more than once, for example when it saved the task but answered after the timeout. Skip any id you already processed.
  • Status. Settings → Webhooks shows when the last delivery succeeded or failed, and the last error.
Tasks that are not new do not trigger the event. Examples are a repeat call that Answering Agent links to an existing task, or a conversation merged into another one.

Other events

task.created is the only event today. To read anything else, such as transcripts, task status changes, or report numbers, call the Customer API.