Payload Reference

Every Aura webhook ships in the same envelope. The data object's shape depends on the event type. This page documents each shape exactly as it appears in production.

Envelope

interface WebhookPayload<T> {
  event: WebhookEventType;     // e.g. "call.booked"
  created_at: string;          // ISO 8601, UTC
  organization_id: string;     // The org the event belongs to
  data: T;                     // Resource payload — see below
  idempotency_key?: string;    // Stable across retries — see below
}

Exactly-once with idempotency_key

Delivery is at-least-once: if your endpoint commits its side effect and then crashes (or times out) before returning a 2xx, Aura re-POSTs the same event. The retry carries the same idempotency_key — created_at and the signature timestamp are recomputed, but the key is not.

Enforce exactly-once by storing the key and rejecting duplicates:

-- One row per (subscription, event). The conflict drops the redelivery.
CREATE UNIQUE INDEX uq_webhook_dedup
  ON processed_webhooks (subscription_id, idempotency_key);

// On each delivery, insert-or-ignore before processing.
const inserted = await db.query(
  `INSERT INTO processed_webhooks (subscription_id, idempotency_key)
   VALUES ($1, $2) ON CONFLICT DO NOTHING RETURNING 1`,
  [subscriptionId, payload.idempotency_key],
);
if (inserted.rowCount === 0) {
  return res.status(200).send('OK'); // already processed — drop silently
}
// ... process the event exactly once ...

LeadWebhookData

Emitted on lead.created, lead.updated, lead.status_changed.

source object

consent entries

One entry per consent box, in the order Aura recorded them. This includes your own boxes on the booking form. Aura's box for appointment texts is in the list once the person has seen it, or replied STOP or START.

Before you text anyone, keep these in mind:

• An empty list means no consent is on file. That is not the same as declined, but it is still not a yes. Treat it as no consent. One exception: for Booking texts, check consent_by_type.sms_booking, which can read yes or no on some older leads whose list is empty (see consent_by_type).
• agreed is false when they agreed for a different number. phone says which number that was.
• Consent can change after the webhook is sent. For example, the person may reply STOP. Read the lead again with GET /v1/leads/:id right before you text them.
• A box they did not tick is only recorded once they finish the form. Someone who leaves halfway has no declined entry yet.

consent_by_type object

One answer for each kind of message, so you can skip people who did not agree without reading each box's wording. Your team chooses which consent box asks about each kind, in Settings. Until a box has a kind, only Booking texts can have an answer, from Aura's own box for appointment texts. Every other kind reads not_asked.

Each answer has the same four fields:

• not_asked is not a yes. It means nothing the person answered asks about that kind of message. Treat it as no consent.
• Booking texts can come from Aura's own box. When your booking page shows Aura's box for appointment texts, its answer comes first, so a STOP reply reads as no.
• Every surface sends the same answers for the same lead: the REST API, GraphQL (Lead.consentByType), the lead webhooks, Zapier and your CRM.
• Booking texts also reads Aura's texting settings. Some older leads have their choice on Aura's box for appointment texts, or their STOP reply, only in Aura's texting settings. Their Booking texts answer reads that choice, as your CRM does, with source aura_sms_opt_in and at set to when they chose. consent lists only the answers Aura has stored, so on these leads it can be empty or leave out the box that Booking texts' id names. Aura adds that box when it next sends the lead to your CRM. lead.deleted already lists it.
• If Aura cannot check your booking page's settings at that moment, for example during an outage, Booking texts reads Aura's own box first for a lead who answered it. That way a STOP reply never reads as yes.

Lead pipeline_stage values

The same columns, in the same order, as the Opportunities board.

status and pipeline_stage can disagree for a while. When a guest accepts the invite, pipeline_stage says confirmed at once, while status can still say booked until Aura's status sync updates it. pipeline_stage is null only if Aura could not read the lead's calls.

Lead status values

CallWebhookData

Emitted on call.booked, call.updated, call.started, call.completed, call.canceled, call.rescheduled, call.no_show.

call.cancelled payload

call.cancelled is the booking funnel's cancel event, and it is the one event that does not use the envelope above. Its body is the flat booking payload: the call's fields sit at the top level, with "event": "call.cancelled", and there is no data wrapper. Verify it with X-Aura-Signature-V1; it does not carry the legacy X-Aura-Signature.

It replaces call.canceled, which takes no new subscriptions. Moving a subscription from call.canceled to call.cancelled changes the body as well as the event name, so update how your handler reads it.

LeadDeletedWebhookData

Sent on lead.deleted. It holds the lead as it was when Aura removed it. You can't look the lead up after this, so this is the last copy of these fields.

CallCloserReassignedWebhookData

Emitted on call.closer_reassigned. This is the only call event with a non-CallWebhookData shape — it carries the swap details rather than the full call record.

CallAnalysisWebhookData

Emitted on call.analysis_completed. Fired when the AI review of a call finishes. Carries headline scores for routing/alerting plus analysis_url for the full review — the full analysis body is intentionally not inlined (tens of KB of evolving JSON).

PaymentWebhookData

Emitted on payment.succeeded, payment.failed, payment.refunded.

Conventions

Timestamps

All timestamps are ISO 8601 UTC (Z suffix):

2026-05-12T14:30:00.000Z

Null handling

Optional fields are emitted as null rather than omitted. Always treat the contract as nullable for any field marked string | null here:

const phone = data.phone ?? "(not provided)";

Forward compatibility

Aura may add new fields to any payload without a major version bump. Consumers must ignore unknown fields. Removing or renaming a documented field is a breaking change and will trigger a schema-diff review on our side before shipping.

Payload version

Every webhook envelope carries the payload contract version in version, and every Zapier payload carries the same value in aura_version. It is the version of the Aura Zapier app, so the two always match.

In October 2026 it jumped from 1.8.5 to 1.11.0. Nothing in the payload changed with that jump: the value had fallen behind the Zapier app, and now it is pinned to it. The next release, 1.12.0, adds the consent fields, 1.13.0 hides the Lead Status Changed trigger, 1.14.0 adds form_completed to lead.disqualified, 1.15.0 adds the lead.deleted event, 1.15.1 changes only how Lead Disqualified is described: it fires 3 minutes after a lead stops, not 30, 1.16.0 adds deal payments to call.closed, and 1.17.0 adds consent_by_type. Treat version as information. Don't branch on it: check for the fields you need instead.

Verifying signatures

Webhook deliveries carry a signed header X-Aura-Signature-V1 of the form:

X-Aura-Signature-V1: t=1715520600000,v1=<sha256_hex>[,v1=<previous_sig>]

The signed string is ${timestamp}.${rawBody} — not the body alone — which prevents replay attacks. Reject deliveries whose t differs from your server clock by more than 5 minutes.

During a 24-hour secret rotation window, two v1= segments are present. Accept the delivery if either signature verifies — this lets you rotate secrets with zero downtime.

The legacy bare-hex X-Aura-Signature header is still sent for backwards compatibility but offers no replay protection; new integrations should verify the V1 header only.

Next steps

• Event Types — when each event fires
• Webhooks Overview — setup, retries, SSRF rules
• API Reference — the same data, but pull-based