Skip to main content
A complete reference for the Webhook Management API. These endpoints let you register a callback URL for a developer app, reveal its signing secret, send test events, and inspect, audit, and retry every delivery attempt.
  • 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:
  1. Create a webhook for one of your developer apps, choosing a service_type (e.g. whatsapp).
  2. Fetch the signing secret and store it, so you can verify the X-Briq-Signature header on incoming deliveries.
  3. Return 2xx quickly from your endpoint. Non-2xx responses, timeouts, and connection errors are treated as failures and retried.
Each emitted event is persisted as a delivery row and attempted by Briq’s delivery engine. You can list deliveries, view a single delivery’s full payload, see aggregate stats, and manually retry failed deliveries.
One webhook per app per service_type. Each developer app may have only one webhook for a given channel. Creating a second whatsapp webhook for the same app returns 400. Delete the existing one first to free the slot.

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 (no success/data/errors envelope). Errors use the raw framework shape:
Treat any non-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:
The returned 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:
Treat the secret as a credential. Store it in a secret manager or environment variable; never expose it client-side. The full HMAC verification procedure (header format, raw-body handling, sample code) is documented in the WhatsApp reference -> Verifying the signature.

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:
Synthetic sms.sent payload quirk. The test endpoint currently emits a synthetic sms.sent event regardless of the webhook’s service_type. For a whatsapp webhook this still verifies connectivity and signature verification, but the body is not a faithful WhatsApp event payload. A native whatsapp.* test event is upcoming.

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:
Delivery summary fields
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.
  • Karibu WhatsApp API - WhatsApp send/read endpoints and the whatsapp.sent/delivered/read/failed event 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.