Skip to main content
This is the complete catalogue of webhook events Onboard Business can deliver to your registered webhook URL. Each product guide links back to the subset relevant to it; this page is the authoritative reference for all of them. Every delivery uses the envelope described in Webhook Verification:

​
Account activity events

Fired when something changes about an account, sub-account, or a saved beneficiary/offramp account — not a movement of money.

​
Transaction activity events

Fired for money movement. Each activity type emits four lifecycle events: .created, .updated, .completed, .failed. Lifecycle suffixes:
  • .created — the activity was created. data.status is typically PENDING.
  • .updated — a non-terminal status change. data.status is typically IN_PROGRESS.
  • .completed — reached a terminal success state. data.status is SUCCESS.
  • .failed — reached a terminal failure state. data.status is FAILED.
The event name’s suffix (.completed, .failed, …) describes the lifecycle transition that triggered delivery. The payload’s own status field is always one of the four TransactionStatus values above — there is no COMPLETED status value; the terminal success state is SUCCESS.
A single underlying transaction can emit more than one event of the same name — for example, one for a sub-account’s activity row and one for its parent main-account row. Treat deliveries as at-least-once and deduplicate on the payload’s activity id, not on event name plus timestamp.

​
Sample payloads

Every sample below is constructed directly from the corresponding schema object in the OpenAPI spec — the same shape you’d get back from the matching REST endpoint.

​
Account activity samples

All three sub-account lifecycle events share the SubAccount shape. .updated and .deleted deliveries reflect the sub-account’s state at the time of the change (e.g. frozen: true for a freeze, or the balance at deletion).
The destination account details generated for a cash deposit virtual account number. The event fires on whichever account or sub-account requested the account number; the request itself (not the payload) tells you which.

​
Transaction activity samples

Every transaction_activity.* payload is a TransactionActivity — a common envelope (id, type, direction, amount, currency, status, accountId, accountType, activityAt, …) plus an activityData object whose shape depends on activityType, per the discriminator on the TransactionActivity schema.
Both crypto event families share the AccountTransaction shape for activityData; only direction and activityType differ.
activityData extends CashPaymentTransaction with offrampAccountId and blockchainInfo.