What counts as success
A delivery is considered successful when your endpoint returns any 2xx HTTP status code. Any other response (or a timeout) triggers a retry.Retry schedule
Failed deliveries are retried with exponential backoff, capped at 240 seconds. The delay formula is:| Attempt | Delay | Cumulative time |
|---|---|---|
| 1 | 1 second | 1s |
| 2 | 2 seconds | 3s |
| 3 | 4 seconds | 7s |
| 4 | 8 seconds | 15s |
| 5 | 16 seconds | 31s |
| 6 | 32 seconds | ~1 min |
| 7 | 64 seconds | ~2 min |
| 8 | 128 seconds | ~4 min |
| 9 | 240 seconds | ~8 min |
| 10 | 240 seconds | ~12 min |
failed and no further retries are made.
Retries are backed by Durable Object alarms, which means they survive infrastructure restarts and are guaranteed to execute.
Request timeout
Each delivery attempt has a 30-second timeout. If your server doesn’t respond within 30 seconds, the attempt is treated as a failure and the next retry is scheduled.Delivery statuses
| Status | Meaning |
|---|---|
pending | Delivery is in progress or awaiting retry |
success | Your endpoint returned a 2xx response |
failed | All 10 retry attempts were exhausted without a 2xx response |
Viewing delivery logs
In the Bluvo Portal, navigate to Settings > Webhooks, select an endpoint, and click Deliveries to view the log. Each delivery record includes:| Field | Description |
|---|---|
| Event type | The webhook event (e.g., wallet.created) |
| Event ID | The unique eventId from the payload |
| Status | pending, success, or failed |
| Attempts | Number of delivery attempts made |
| Response status | HTTP status code returned by your server |
| Response body | First 1,000 characters of the response body |
| Error message | Error details if the delivery failed (e.g., timeout, connection refused) |
| Timestamps | When the delivery was created and last attempted |
Tips
Respond fast, process async
Respond fast, process async
Immediately return
200 OK and enqueue the event for asynchronous processing. This prevents timeouts and keeps retry counts low.Don't rely on delivery order
Don't rely on delivery order
Events may arrive out of order, especially when retries are involved. Use the
timestamp field in the payload to determine event ordering if needed.Deduplicate with eventId
Deduplicate with eventId
The same event may be delivered more than once. Track processed
eventId values to avoid duplicate handling.Monitor for failed deliveries
Monitor for failed deliveries
Regularly check the delivery logs in the Portal. If an endpoint consistently fails, verify the URL is reachable and returning 2xx responses.