Last published: 2026-06-01
Webhooks at Baack provide a robust, event-driven mechanism to move from a "pull" model to real-time integrations. With over 80% of the API surface covered, webhooks allow your application to receive instant updates whenever data changes on the platform.
Before setting up webhooks, you must have a valid API Client and a Bearer Token if you intend to use Bearer authentication for your administrative requests to the Baack API.
webhook.baack.co. Only clients scoped to the webhooks sub-domain can subscribe to events. This restriction prevents webhook clients from accessing general api scopes.Baack supports fine-grained subscriptions, allowing you to "listen" only to the specific events your product requires.
Subscriptions can be configured for individual subjects (e.g., a specific message thread) with the following event types:
To manage these, use the Webhook Subscription endpoint.
Baack offers flexible, standards-based authentication mechanisms to ensure that delivery to your integration is secure and compatible with your existing infrastructure.
| Authentication Method | Description |
|---|---|
| HTTP BASIC | Uses the API Client ID as the username and the Subscription Secret as the password. |
| DIGEST | Standard challenge-response mechanism using the following formulas: HA1 = MD5(username:realm:password) HA2 = MD5(method:digestURI) response = MD5(HA1:nonce:HA2) |
| BEARER | Standard token-based authentication using the Bearer token associated with the API Client. |
| mTLS | Mutual TLS for high-security environments; available upon request. |
| HMAC-SHA256 | Signature-only verification. The signature is calculated as: HMAC-SHA256(payload, secret) payload = body + timestamp + idempotencyKey |
Note: the signature is always provided.
The delivery mechanism prioritizes speed and reliability through a "fast-then-slow" retry strategy. Initial delivery attempts are rate-limited based on your subscription's events-per-minute configuration.
Integrations should use the Idempotency-Key header (the trigger URN) to detect duplicates. For versioned resources, the vectorClock field should be used to ensure updates are processed in the correct order.
The payload is intended to be as simple as possible to allow an integration to determine how to route the update. Webhook event messages do not provide the content of the representation for security reasons.
Failed deliveries due to timeouts (HTTP 408, 418) or server errors (HTTP 429, 503, 504) follow an exponential back-off schedule (approx. 8s, 16s, 60s, 8m, etc.), with the final attempt occurring roughly 16 hours after the initial failure.
If retries all fail or if there are a significant number of delivery failures then the subscription will expire automatically. Please verify that the endpoint is functional before re-enabling the subscription as delivery attempts count against your billable requests.
To ensure the integrity and authenticity of the data received, every webhook includes security headers to prevent spoofing and replay attacks.
For assistance with integration testing or to request mTLS setup, please contact support@.