Skip to main content
Updated Nov 1, 2026

Webhooks

What you'll learn
  • What webhooks are and how they work in AutoTalk
  • What each delivery contains and how deliveries behave
  • How to create and manage webhook endpoints

Webhooks send real-time notifications to external services when events happen in AutoTalk. Instead of repeatedly checking AutoTalk's API for new data, your external system receives an automatic notification the moment something happens, such as a new message arriving or a contact being updated.

You manage webhooks from the Webhooks page under Integrations in the sidebar.

How webhooks work​

  1. You provide a Webhook URL (an endpoint on your server or a third-party service that can receive HTTP requests).
  2. You pick a data Model and an Operation (for example, contacts + afterCreate) that should trigger the webhook, and optionally a CEL Filter to narrow which changes fire it. Your own Custom Types work too — pick the ct:<slug> entry in the Model dropdown (for Custom Types, the afterCreate, afterUpdate, and afterDelete operations fire).
  3. When a matching change occurs in AutoTalk, the platform sends an HTTP POST request to your Webhook URL with the event data in JSON format.

Your external system receives the data and can act on it however you need, whether that means updating a database, sending a notification, or triggering a workflow.

The Model dropdown is a fixed set

The dropdown offers a fixed set of built-in models plus your own Custom Types as ct:<slug> entries. The built-in models you can pick are contacts, conversations, messages, agents, workflows, and webhooks — no other model can be selected there. To react to anything else, build a workflow with a hook trigger and an HTTP request step instead of a webhook.

The filter​

The filter is a CEL expression over doc (the record), prev (its previous version, or null), companyId, type, op and now. It sees them the way a workflow hook filter does: every id is its 24-character hex string and every date an ISO 8601 string, so compare ids directly, for example doc.contactId == "65f0c1d2e3a4b5c6d7e8f901".

A filter that fails — an error, such as reading a field the record does not have, or running past 1000 ms — never delivers the webhook, whatever its On failure setting says. Guard a field that may be missing or null: has(doc.channel) && doc.channel != null && doc.channel.kind == 'whatsapp'.

Delivery payload​

Each delivery is an HTTP POST request with a JSON body in a stable shape:

{
  "id": "contacts:afterCreate:66a1b2c3d4e5f6a7b8c9d0e1:2026-07-02T14:03:07.512Z",
  "model": "contacts",
  "op": "afterCreate",
  "at": "2026-07-02T14:03:07.512Z",
  "companyId": "664a0f9eb1c2d3e4f5a6b7c8",
  "tenantId": "664a0f9eb1c2d3e4f5a6b7c8",
  "doc": {
    "_id": "66a1b2c3d4e5f6a7b8c9d0e1",
    "name": "Jane Doe",
    "createdAt": "2026-07-02T14:03:07.498Z",
    "updatedAt": "2026-07-02T14:03:07.498Z"
  },
  "prev": null
}
FieldMeaning
idA per-event identifier combining the model, operation, record id, and timestamp
modelThe data model that changed — a built-in model like contacts, or ct:<slug> for a Custom Type
opThe lifecycle operation that fired the webhook (for example afterCreate, afterUpdate, afterDelete)
atWhen the event fired, as an ISO 8601 timestamp
companyId / tenantIdYour company's id (both fields carry the same value)
docThe record involved in the event (the example above is truncated — you receive the full record)
prevThe record's previous version, when one exists (updates); null otherwise (for example, on creates)
note

For Custom Type (ct:) afterDelete deliveries, doc is not the deleted record — it is a {filter, hardDelete, deletedCount} summary object describing the delete, and prev is always null.

Delivery semantics​

  • Each event gets a single delivery attempt per webhook — failed deliveries are not retried.
  • The request times out after 5 seconds, and redirects are not followed — point the webhook directly at an endpoint that responds quickly.
  • Respond with any 2xx status to acknowledge receipt; the response body is not parsed, but it must stay under 64 KiB — a larger response aborts the delivery and counts as a failure.
  • AutoTalk records failed deliveries in its platform logs and delivery metrics, but there is no per-webhook delivery log you can open in the app — if you need a record of what your receiver got, log every request on your side.
  • Deliveries are not signed. If your receiver needs to verify that a request really came from AutoTalk, include a hard-to-guess token in your Webhook URL (for example, a secret query parameter) and check it on your side.

Managing webhooks​

Viewing existing webhooks​

Navigate to Integrations > Webhooks. The page displays a list titled Webhooks with all of your configured endpoints. The list follows AutoTalk's standard CRUD format with options to filter, view, edit, and delete entries.

Creating a new webhook​

  1. On the Webhooks page, click the + button (tooltip "Add new webhooks").
  2. Fill in the fields:
    • Webhook URL — The endpoint where AutoTalk should send event data (must be a public HTTP/HTTPS URL)
    • Enabled — Whether the webhook fires (on by default)
    • Trigger — A Model, an Operation, and an optional CEL Filter that decide which changes fire the webhook. The Model list is the fixed set described in How webhooks work.
  3. Save the webhook.

AutoTalk will now send an HTTP POST request to your Webhook URL every time a matching change occurs.

Editing or deleting a webhook​

  • Click on any webhook in the list to view its details and modify its configuration.
  • To stop notifications to a specific endpoint, delete the webhook from the list.

Next steps​

Last updated on
On this page