Webhooks are a way for you to receive near real-time events of what’s happening on the platform.

​
Event types

Each group of endpoints has its own set of events that you can subscribe to. For example, the Users group of endpoints of the Core API has events like core.user.created, core.user.deleted, etc. You may find the list of events that you can subscribe to in the documentation of the group of endpoints you are interested in.

​
Consistent shape

Every webhook event has a consistent shape, with the following structure: 
{
  // A unique identifier for the event.
  "id": "6a3d8cea-5250-4bd0-a443-eb07b04c85d4",
  // The type of the event.
  "type": "core.users.created",
  // The timestamp at which the event was created.
  "createdAt": "2025-02-20T21:21:09.943Z",
  // The data associated with the event, specific to the event type.
  "data": {}
}

​
Signature check

To prevent attackers from impersonating services by sending fake webhooks, each webhook delivery is signed with a unique key specific to the receiving endpoint. This signature allows you to verify that the webhook is genuinely from us and ensures that only legitimate webhooks are processed. Each webhook call includes three headers with additional information that are used for verification:
  • Webhook-Id: The unique message identifier for the delivery. This identifier will be the same when the same webhook is being resent (e.g. due to a previous failure).
  • Webhook-Timestamp: Timestamp in seconds since epoch of when the webhook was sent.
  • Webhook-Signature: The Base64 encoded list of signatures (space delimited).
To know more about how to verify the signature, please refer to the Webhook Signature Verification from our webhook provider: Svix. They offer a SDK for different languages to help you with the verification process or you can implement the verification manually by following their guide.
Do not confuse Webhook-Id and Webhook-Timestamp headers with id and createdAt fields in the event payload. The former are headers sent by Svix and are scoped to a delivery, while the latter are fields generated by our platform.

​
Retry Schedule

When a webhook delivery fails (e.g., due to a non-2xx response or timeout), the system will automatically retry the delivery based on an exponential backoff strategy. The schedule starts with short intervals and gradually increases over time, helping to avoid overwhelming the receiver. Retries continue for up to 24 hours or until a successful response is received. In addition to automatic retries, you can also trigger manual redelivery attempts through the Enterprise Portal, under the Webhooks section. This is useful for immediate reprocessing or debugging. For detailed information on the retry behavior, refer to the retry policy from our webhook provider: Svix.

​
Subscribing to Webhooks

The easiest way to subscribe to webhooks is through the Webhooks Portal. Not only that, but you can also check delivery logs and test your webhook endpoint to ensure it is working correctly. There are two ways to get access to the Webhooks Portal:

​
IP whitelisting

In case your webhook receiving endpoint is behind a firewall or NAT, you may need to allow traffic from Svix’s IP addresses, our webhook provider. You can find the list of Svix’s IP addresses at https://docs.svix.com/webhook-ips.json.