Webhooks allow a subscription URL to be configured that we will POST event data
to as it is added to the Event Log. Each subscription
is configured to trigger when an event matches a set of
object types and actions.
Here is an example of the Webhook data for an opportunity that was won. This
would be sent to the URL you provide using a POST request:
Webhook delivery
- Failed deliveries are retried with a retry interval that exponentially backs
off up to every 20 minutes. They will be retried up to 72 hours before being
dropped.
- Event ordering is not guaranteed due to
event consolidation, delivery
parallelism/retries and other factors.
- A subscription will automatically be paused and its queue cleared when one of
following happens:
- Event queue reaches 100,000 backlogged events. Warning emails will be sent
to admins when there is more than 80,000 backlogged events.
- All event delivery fails for 3 days. Warning emails will be sent to admins
before the subscription is paused.
- Email notifications are sent to admins when a subscription is paused.
- Paused subscriptions must be manually re-activated via the API before we will
attempt to deliver events again.
- We recommend processing Webhook events asynchronously meaning that you queue
them locally before trying to process the payload. This will ensure we are
always able to deliver the event and avoid the possibility of subscriptions
getting paused because the max queue length is reached.
- If your application needs to reprocess historical events, you can access them
via the event log API for up to 30 days.
- For
updated or deleted actions the webhook will be called after the
consolidation delay.
- Event updates are written immediately to the event log during the
consolidation period so if you query the event log directly you may see events
that you haven’t received a webhook notification for yet.
Data management
- Users with the Admin role can manage subscriptions for all users in the
organization. Non-admin users can only modify subscriptions created by them.
- All data is delivered in the Webhook event even for non-admin users since they
would have access to the same data via the application at delivery time.
- We recommend using https to protect your data during delivery. SSL certificate
validation is enabled by default but can be disabled via the
verify_ssl
field.
Webhook signatures
The subscription API’s POST response includes a signature_key value that will
be used to sign Webhooks for the subscription. The signature and signing
timestamp is available in the following two headers of each POST request to your
endpoint.
The signature in the close-sig-hash header is the sha256 HMAC of the
close-sig-timestamp and payload concatenated. The following Python 3 example
code demonstrates how the signture can be verified.
See the Subscription API documentation for
the details of managing Webhook subscriptions.
Limits
The maximum number of webhook subscriptions per organization is 40. However, we
allow a higher limit of webhook subscriptions to specific automation platforms
(up to a total of 500 subscriptions).
These platforms are: