Skip to main content
Webhooks allow you to receive real-time HTTP notifications when data changes in your Archie Core project. When a record is created, updated, or deleted, Archie Core sends a POST request to your configured URL with the event details.

How webhooks work

  1. Register a webhook subscription specifying the table, events, and target URL
  2. Data changes — when a matching mutation occurs (via REST API or GraphQL), an event is published
  3. Delivery — the webhook service sends an HTTP POST to your URL with the event payload
  4. Verification — validate the HMAC signature to ensure the request is authentic

Webhook management API

All webhook management endpoints are under /api/rest/_webhooks and require a management API token.

Required headers

Important: The environment header is required for all webhook management endpoints. The header value must match the environment field in the request body when creating or updating webhooks.

Endpoints

Create a webhook

Request

Request body

Optional filtering

Only fire the webhook when specific conditions are met:

Field selection

Limit which fields are included in the event payload:
Response (201 Created)

List webhooks

Get webhook details

Returns the webhook subscription along with its recent delivery history.

Update a webhook

Delete a webhook

Event payload

When a data mutation occurs, the webhook service delivers an HTTP POST to your URL:
Note: For DELETE events, record and data contain the record as it was before deletion. The changed_fields array is empty for INSERT and DELETE events.

Delivery headers

Each webhook delivery includes these headers:

Verifying signatures

Every delivery is signed using HMAC-SHA256 with the webhook’s secret. Always verify the signature before processing the payload.

Node.js example

Python example

Retry policy

If your endpoint returns a non-2xx response or is unreachable, the webhook service retries delivery with exponential backoff: After the maximum retry attempts, the delivery is moved to a dead letter state and can be inspected via the webhook details endpoint.

Circuit breaker

If an endpoint fails consecutively, the webhook service activates a circuit breaker to protect your endpoint:
  • Opens after 5 consecutive failures per endpoint
  • Cooldown period: 2 minutes
  • During cooldown, deliveries are queued and retried after the cooldown expires

Best practices

  • Always verify signatures — never trust a webhook payload without HMAC verification
  • Respond quickly — return a 200 status within 5 seconds; process events asynchronously if needed. Long-running handlers are the natural use case for custom functions — the webhook receiver dispatches to a function, which acknowledges immediately and processes in the background.
  • Handle duplicates — use the event id to implement idempotent processing
  • Use HTTPS — webhook URLs must use HTTPS for secure delivery
  • Monitor deliveries — check the webhook details endpoint regularly to catch persistent failures

FAQ

The integration’s settings page in your project shows the URL to register.
Return a 200 status within 5 seconds. Process longer work asynchronously and acknowledge the delivery first.
Yes — the webhook details endpoint (GET /api/rest/_webhooks/:id) returns recent deliveries with status, HTTP code, attempts, and timestamp.