Skip to main content
Biqli queues webhook delivery after the product event commits. A webhook outage does not roll back the original link or conversion event.

Successful delivery

Any HTTP status from 200 through 299 counts as successful. Return quickly after your application safely stores or queues the event. Redirects are not followed. An HTTP 3xx, 4xx, 5xx, connection failure, timeout, or unsafe DNS result counts as a failed attempt.

Retry schedule

Biqli makes up to six total attempts. After each of the first five failures, the next attempt is scheduled approximately:
  1. 12 seconds later
  2. 2 minutes 28 seconds later
  3. 30 minutes 8 seconds later
  4. 6 hours 7 minutes later
  5. 24 hours later
After the sixth failed attempt, the delivery is marked failed.
Your receiver must still deduplicate events. A timeout can occur after your server accepted the body but before Biqli received the response.

Request limits

  • Connection timeout: 5 seconds
  • Total request timeout: 15 seconds
  • Maximum downloaded response: 1 MB
  • Stored response body: first 65,535 bytes
  • Redirect following: disabled
Keep response bodies small. A short 200 OK response is sufficient.

Endpoint health

A successful production delivery resets the endpoint’s consecutive-failure count. A delivery that exhausts all attempts increments it. Biqli notifies the workspace owner at 5, 10, and 15 consecutive failed deliveries. At 20 consecutive failures, Biqli disables the endpoint and notifies the owner again. Test deliveries do not change endpoint health.

Inspect a failure

Open Workspace settings -> Webhooks, select the endpoint, and open the delivery. The detail view contains:
  • event ID and event type;
  • delivery status and attempt count;
  • request URL, headers, and payload;
  • response status, headers, and stored body;
  • duration and error for every attempt;
  • next-attempt and completion times.
Fix the receiver, then send a test event. Re-enable an automatically disabled endpoint only after the test succeeds.