Skip to main content
Customer-configurable outgoing webhooks are currently a preview. The subscribable event types below mirror the backend’s canonical event catalog.
Webhook event types use a resource and lifecycle name such as email.delivered, contact.updated, or broadcast.sent.

Common envelope

Webhook deliveries use the canonical versioned event envelope:
version is currently "1". object_type is fixed by the event type, and all currently subscribable events require an object_id. The data object contains the resource-specific event payload. Treat unknown fields and future event types as forward-compatible additions. Do not fail an entire endpoint because it receives data your application does not use.

Subscribing to events

A webhook endpoint must subscribe to at least one supported event. Empty values and duplicate event names are removed during validation. An unsupported event name causes the endpoint create or update request to fail with 400 Bad Request. webhook.test is not a subscribable event. It is generated only when you test a specific endpoint.

SMS events

Email events

Email event payloads may include recipient-level state and provider diagnostics. Engagement and subscription events do not imply a delivery-state transition.

Contact events

Suppression events

Broadcast events

Test events

Sending a test from an endpoint creates a webhook.test event targeted only to that endpoint. It uses the canonical envelope with object_type set to webhook_endpoint, but it cannot be included in subscribed_events.

Delivery headers and signature

Each request includes:
  • X-Dugble-Event: event type
  • X-Dugble-Event-Id: stable event UUID
  • X-Dugble-Delivery-Id: UUID for this endpoint delivery
  • X-Dugble-Signature: timestamped HMAC signature
The signature has the form t=<unix_timestamp>,v1=<hex_digest>. Compute the expected digest with HMAC-SHA256, using the endpoint signing secret as the key and <unix_timestamp>.<raw_request_body> as the signed bytes. Compare digests with a constant-time function and reject timestamps outside your tolerance.

Signature verification

Follow the complete signing contract and verification examples.

Idempotent handling

Your endpoint should:
  1. Verify the webhook signature against the raw request body.
  2. Store the event ID with a unique constraint.
  3. Acknowledge duplicate IDs without repeating side effects.
  4. Queue application work and respond quickly.
  5. Log unknown event types rather than returning an error.