Signed with HMAC-SHA256
Every request carries a timestamp and signature header. Verify both before you trust the body.
Developers
Webhooks you can reconcile against
Money movement is asynchronous. Our event stream is signed, ordered per resource and replayable, so your ledger never drifts.
Retried for 24 hours
Any non-2xx response is retried with exponential backoff, then parked for manual replay.
At-least-once delivery
An event may arrive more than once. Key your handler on the event id and make it idempotent.
Ordered per resource
Events for a single resource are delivered in sequence, so a reversal never precedes its payout.
Example payload
{
"id": "evt_01HQ8ZT4KX",
"type": "payout.completed",
"created_at": "2026-07-26T09:14:02Z",
"api_version": "2026-04-01",
"data": {
"payout_id": "po_8812",
"beneficiary": "acc_9f2c41",
"amount": 124500,
"rail": "IMPS",
"utr": "IMPS0921884412"
}
}Headers: Rubix-Signature and Rubix-Timestamp.
Verify before you trust
import { verifyWebhook } from '@rubixpe/node'
export async function POST(request: Request) {
const raw = await request.text()
const event = verifyWebhook({
payload: raw,
signature: request.headers.get('Rubix-Signature'),
timestamp: request.headers.get('Rubix-Timestamp'),
secret: process.env.RUBIXPE_WEBHOOK_SECRET,
})
await queue.enqueue(event)
return new Response(null, { status: 200 })
}Event catalogue
| Event | Product | Meaning |
|---|---|---|
| payout.completed | RubixSwitch | Funds credited to the beneficiary account and the ledger entry finalised. |
| payout.reversed | RubixSwitch | The rail returned the transfer and your pool balance has been restored. |
| collection.received | RubixSwitch | An inbound credit landed on a virtual account and matched an invoice. |
| verification.finished | RubixVerify | A verification journey reached a final approve, reject or manual-review decision. |
| order.routed | RubixRoute | An order was authorised through the gateway selected by the routing engine. |
| settlement.posted | RubixRoute | A settlement batch was posted with a reconciled fee and tax breakdown. |
Handler best practices
- Return 2xx as soon as you have persisted the event, then process asynchronously.
- Verify the signature before parsing JSON so malformed payloads cannot reach your logic.
- Reject any event whose timestamp is older than your replay window.
- Treat the API as the source of truth and re-fetch the resource for critical state changes.
- Allowlist our published egress ranges if your endpoint sits behind a firewall.
Need help with your event pipeline?
Our integration engineers will review your handler design and replay production-shaped traffic at it in sandbox.