Skip to main content
Your receiver must be publicly reachable over HTTP or HTTPS. Use HTTPS in production.

​
Create the receiver first

Build a route that:
  • accepts POST with a JSON body;
  • reads the exact raw request body;
  • verifies Biqli-Signature;
  • deduplicates the envelope id;
  • returns an HTTP 2xx response quickly.
Do not require browser cookies, CSRF tokens, or interactive authentication on this route. The HMAC signature authenticates Biqli’s payload.

​
Register it in Biqli

Create the endpoint, choose its event subscriptions, and copy the whsec_... signing secret into your server-side secret manager. Send a test event before enabling production work. The dashboard workflow and delivery-log controls are documented in Manage workspace webhooks.

​
URL safety rules

Biqli validates the destination at configuration time and again immediately before every attempt.
  • The URL must use HTTP or HTTPS.
  • Credentials embedded in the URL are rejected.
  • localhost, private addresses, and reserved network addresses are rejected.
  • The hostname must resolve publicly.
  • Redirect responses are not followed and count as failures.
  • One workspace cannot configure the same normalized URL twice.
The URL is re-resolved for every delivery to prevent a later DNS change from reaching an internal service.

​
Runtime behavior

Disabling an endpoint stops new production events from being queued. A pending or retrying production delivery is cancelled when its job next runs; test deliveries can still be sent for diagnosis. Existing history remains visible. Deleting the endpoint removes its associated delivery records.

​
Permissions

Workspace access follows the webhook permissions assigned to the member: view, create, update, and delete. A member cannot use webhook access to read or modify another workspace’s endpoints.