Opening your next page
Developers
Create protected payment links, monitor the payment state, and receive lifecycle webhooks - before you ever build your own trust ledger.
API access is by request: sign in, tell us what you're building, and our team reviews it and emails you the decision. Then you create test keys and build against the sandbox before going live.
POST /api/v1/checkouts creates a request and returns a hosted funding link.
Every payment has an explicit state: awaiting payment, funded (funds received into trust), released, paid out, refunded, cancelled or failed. Holds and disputes are shown separately.
Subscribe to lifecycle webhooks and verify them with the signing secret shown once when you create the webhook endpoint.
Request shape
You create the request. Wlbr hosts the funding, trust, approval, and payout experience.
POST /api/v1/checkouts
Authorization: Bearer sk_test_...
Idempotency-Key: <one UUID per operation; reuse on retries>
{
"buyer_email": "customer@example.com",
"description": "Website deposit",
"amount": 125000
}Webhook events
Webhook security
Verify wlbr-Signature as t=<unix seconds>,v1=<hex HMAC-SHA256 of "<t>.<raw body>">. Reject timestamps more than 300 seconds old. During a secret roll there are two v1 values and either may match.
Answer with a 2xx within 5 seconds. A notification that is not acknowledged is retried 10 more times over about 5 days, then marked failed; retries are picked up every five minutes, and every attempt is signed afresh. An endpoint that has failed continuously for 3 days, over at least 10 attempts, is turned off and the owners are emailed.
While an endpoint is off, the events it subscribes to are still recorded for it and nothing is sent. When you turn it back on, what it missed in the last 7 days is sent, oldest first: events raised while it was off, and notifications that were still pending when it went off. Anything older is not sent, so after a longer gap read your open checkouts again.
Events can arrive more than once and out of order. Deduplicate by event id, then read GET /api/v1/checkouts/{id} for the current state.
GET /api/v1/events lists the last 30 days of events recorded for your webhook endpoints (with no endpoint registered, nothing is recorded). POST /api/v1/events/{id}/redeliver resends an event.
An Idempotency-Key is honoured for 30 days: within that time the same key and body return the original response. A request that is refused or fails before anything is created does not use the key up, so the same key and body can be sent again once the cause is fixed. If a response is lost and a retry answers 409 idempotency_reconciliation_required, check with GET /api/v1/checkouts?reference=… whether the checkout exists before sending it again with a new key; a checkout sent with a reference is never created twice.
Reference
Each business can make 300 requests a minute with each key mode (test and live are counted separately), and resend up to 30 events an hour. Every response says how many requests are left (X-RateLimit-Remaining); a 429 says how long to wait in Retry-After and when the minute resets in X-RateLimit-Reset.
Sign in and ask for API access. Tell us what you're building and how you expect to use the API. Our team reviews each request and emails you the decision. Once we say yes, you can create a scoped sandbox API key and a separate webhook endpoint, then verify retries and event delivery before moving to live keys.
Building a platform that other sellers connect to Wlbr? Apply to register your partner app from the same page. No seller can connect an app until our team has reviewed it, and each seller needs their own API access too.