Use this file to discover all available pages before exploring further.
Proposed defaults. The retry schedule below follows industry conventions (Stripe’s 3-day, exponential-backoff retry; GitHub’s similar policy). Concrete intervals will be finalized with the BlooBank platform team before this scheme exits “Proposed” status.
❌ Permanent failure. No retry. Visible in Dashboard for manual replay.
Your endpoint responds 5xx
🔄 Transient failure. Retried per schedule.
Connection refused / TLS error / DNS error
🔄 Transient failure. Retried per schedule.
No response within 10 s
🔄 Transient failure (treated as timeout). Retried per schedule.
4xx is permanent. If your endpoint is temporarily broken and you accidentally return 400 or 404, the event is not retried. Either fail-safe to 5xx on any error you cannot classify, or fix the bug and trigger a manual replay from the Dashboard.
When a delivery fails transiently, BlooBank retries on an exponential schedule with jitter. The schedule below is the proposed default:
Attempt
Delay since previous
Cumulative time
1 (initial)
—
immediate
2
~10 seconds
~10 s
3
~1 minute
~1 min
4
~10 minutes
~11 min
5
~1 hour
~1 h
6
~6 hours
~7 h
7
~12 hours
~19 h
8
~24 hours
~43 h
9
~24 hours
~67 h (≈ 3 days)
After attempt 9, the delivery is marked permanently failed and surfaced in the Dashboard. You can trigger a manual replay any time within the 30-day retention window.Actual delays apply random jitter in the range [delay × 0.5, delay × 1.5] to avoid thundering-herd recoveries.deliveryAttempt in the event body and in the X-Bloobank-Delivery-Attempt header carries the 1-based attempt count — use it to recognize that you are receiving a redelivery (not necessarily a new event).
If a delivery fails permanently and you do not catch it within 30 days, the event is gone from BlooBank’s delivery queue. But: the underlying state is still in the resource. You can always:
GET /wallets/{wallet}/paymentOrders/{paymentOrder} HTTP/1.1
The order’s current status is authoritative — webhooks are a convenience layer for push notifications, not the only source of truth. A daily reconciliation pass that compares your local ledger against GET /paymentOrders?filter=...&order_by=createdAt%20desc will catch any missed events.
The 200 OK leaves your endpoint before the real work starts. If the work fails, you have already acknowledged — your retry logic is internal, not via BlooBank redelivery.This pattern keeps BlooBank’s retry contract clean and decouples your reliability from theirs.
The Dashboard allows you to send test events to your endpoint without a real transaction occurring. Use these to validate signature verification, JSON parsing, and downstream handling in non-production environments.
