Skip to main content
The Partner API delivers events to your webhook endpoints in real time. This is the reference for managing subscriptions and the payload of each event type. For the conceptual framing, see Partner → Webhooks.

Manage subscriptions

Create a subscription

Body

string
required
HTTPS URL to deliver to.
array
required
Array of event types to subscribe to.
string
Free-text description for your internal records.

Response 201

Save the secret immediately — it’s shown once. Use it to verify every incoming webhook’s signature.

Update a subscription

Body

string
New URL (optional).
array
New event list (optional).
string
ACTIVE or PAUSED.

Delete a subscription

Returns 204. Deletion is immediate.

List subscriptions

Each subscription includes delivery stats (delivered count, failed count, avg latency over the last 24h).

Delivery shape

Every webhook is a POST to your URL with:

Headers

Body

Verification

The signature header has two fields, comma-separated:
  • t — Unix timestamp when we signed.
  • v1 — HMAC-SHA256 hex over {t}.{raw_body} using your webhook secret.
Verification, in five languages:
Use a constant-time comparison everywhere — hmac.compare_digest (Python), crypto.timingSafeEqual (Node), hash_equals (PHP), CryptographicOperations.FixedTimeEquals (C#), MessageDigest.isEqual (Java). Never use plain string equality.

Event types

Fires when a user grants you a consent (either via consent link or from their dashboard directly).
Fires when a user revokes a previously granted consent.
After receiving this, your subsequent snapshot reads with this consent ID will return 403 consent_revoked. Fires when a consent passes its expiresAt without renewal.
Fires when a user extends a consent that was approaching expiry.

standing.tier_changed

Fires when a user with an active consent changes standing tier.
You’d typically re-fetch a fresh snapshot after this event if you have an active loan with this user — the new tier may indicate the user’s situation has shifted materially.

disbursement.delivered

Fires when a disbursement you initiated successfully reaches the user.

disbursement.failed

Fires when a disbursement fails (typically a name mismatch or bank rejection for BANK_DIRECT).
The funds were never debited from your account; you can retry with a corrected destination.

repayment.settled

Fires when a scheduled repayment direct-debit lands successfully (or a manual repayment from the user’s wallet).

repayment.failed

Fires when a scheduled repayment direct-debit fails (insufficient funds, bank error).
We retry repayment debits on a schedule (typically next business day). If after 3 retries the debit still fails, the loan moves to a default state and we fire a separate event for that.

Retry behaviour

We retry failed deliveries with exponential backoff: A successful 2xx response stops the retries. A 410 Gone response permanently disables the subscription. A 4xx-other or 5xx triggers the next retry.

Idempotency

Every event has a stable id (e.g., evt_01HMFB...). After processing, store the ID. On the next delivery, check the store — if you’ve seen the ID, return 200 immediately without reprocessing. Standard at-least-once delivery semantics.

Webhooks (concept)

The conceptual framing.

Rate limits

Throughput numbers.