- API surface:
https://karibu.briq.tz/v1/webhooks/* - Audience: backend engineers wiring Briq delivery events into their product.
- Version:
v1
The
/v1/webhooks/* routes are shared across all channels. The same routes serve sms, voice, otp, whatsapp, and email - you pick the channel with the service_type field when you create a webhook. For the WhatsApp event payloads delivered to these webhooks, see the Karibu WhatsApp API reference.1. Overview
A webhook is a callback URL Briq POSTs event payloads to when something happens to a message you sent. To receive events you:- Create a webhook for one of your developer apps, choosing a
service_type(e.g.whatsapp). - Fetch the signing secret and store it, so you can verify the
X-Briq-Signatureheader on incoming deliveries. - Return
2xxquickly from your endpoint. Non-2xxresponses, timeouts, and connection errors are treated as failures and retried.
2. Authentication & host
Base URL
Required headers
All webhooks you create, read, or manage are scoped to your developer apps (resolved from the API key). A webhook owned by another user is invisible to you - reads return
404.
Response shape
These endpoints return bare resource objects (nosuccess/data/errors envelope). Errors use the raw framework shape:
2xx status as a failure and read detail for the reason.
3. Endpoint reference
3.1 POST /v1/webhooks/ - Create a webhook
Registers a callback URL for a developer app. The authenticated user must own the app referenced by app_id. A signing secret is generated automatically at creation; retrieve it separately via the secret endpoint.
Body:
Success -
201 Created:
secret_token is always masked as ***. Fetch the real value with the secret endpoint.
3.2 GET /v1/webhooks/all - List all webhooks for the user
Returns every webhook belonging to the authenticated user, across all developer apps and channels. Returns an empty array [] if you have none (not an error).
Success - 200 OK: an array of webhook objects (same shape as the create response).
3.3 GET /v1/webhooks/app/{app_id} - List webhooks for an app
Lists the webhooks registered for a single developer app you own. If the app is not yours or has no webhooks, an empty array [] is returned.
Path parameter: app_id (string, required).
3.4 GET /v1/webhooks/{webhook_id} - Get a webhook
Fetches a single webhook by ID. Must belong to one of your apps, otherwise 404.
Path parameter: webhook_id (string, required).
Success - 200 OK: a single webhook object.
3.5 PATCH /v1/webhooks/{webhook_id} - Update a webhook
Updates a webhook’s url and/or service_type. Both fields are optional; send only what you want to change.
Body:
The signing secret is fixed at creation and is not affected by an update. Existing receivers keep verifying
X-Briq-Signature with the same secret.3.6 DELETE /v1/webhooks/{webhook_id} - Delete a webhook
Permanently removes a webhook. After deletion, Briq stops sending events to its URL, and the per-service_type uniqueness slot is freed (you can create a new one for the same app + channel).
Success - 204 No Content (no body).
3.7 GET /v1/webhooks/{webhook_id}/secret - Reveal signing secret
Returns the webhook’s signing secret in plaintext. Use it to verify the X-Briq-Signature header (HMAC-SHA256 of the raw request body) on incoming deliveries.
Success - 200 OK:
3.8 POST /v1/webhooks/{webhook_id}/test - Send a test event
Enqueues a synthetic test delivery so you can confirm your endpoint is reachable and your signature verification works. Returns an event_id you can use to find the delivery.
Success - 202 Accepted:
3.9 GET /v1/webhooks/{webhook_id}/deliveries - List delivery attempts
Returns a paginated, filterable list of delivery attempts for a webhook so you can audit what was sent, the HTTP status received, and any errors.
Query parameters:
Success -
200 OK:
List items omit the
url and payload fields. Use get-one-delivery for the full payload snapshot.3.10 GET /v1/webhooks/{webhook_id}/stats - Delivery stats
Returns aggregated delivery outcome counts over a time window, broken down by status and event name. Useful for monitoring health and spotting failure spikes.
Query parameter: since (datetime, ISO 8601, optional). Defaults to 7 days ago.
Success - 200 OK:
3.11 GET /v1/webhooks/deliveries/{delivery_id} - Get one delivery
Returns the full detail for a single delivery, including the target url and the payload snapshot of the JSON body that was sent (or is queued to send).
Path parameter: delivery_id (string, required) - the id from a delivery list item.
Success - 200 OK: every delivery-summary field plus:
3.12 POST /v1/webhooks/deliveries/{delivery_id}/retry - Retry a delivery
Schedules a previously failed delivery for another attempt. Only deliveries with status failed or exhausted can be retried.
Success - 200 OK: the updated delivery detail (typically status: "pending" with next_attempt_at set).
Retry requeues the same delivery row - it does not create a duplicate. The same
id is updated and re-attempted.4. What your endpoint must return
The response body is not interpreted for success - 204 No Content or 200 OK with an empty body is sufficient. Respond quickly (acknowledge, then process asynchronously) so your endpoint isn’t marked as failing under load.
5. Related references
- Karibu WhatsApp API - WhatsApp send/read endpoints and the
whatsapp.sent/delivered/read/failedevent payloads delivered to these webhooks. - Webhooks (subscriber guide) - what your HTTPS endpoint receives, signature verification, idempotency, and retry behavior.
- Developer Apps - API keys and app configuration.