Skip to main content

Event types

Delivery headers: X-RAAS-Event, X-RAAS-Timestamp, and X-RAAS-Signature. See Webhook security.
New event types may appear. Always acknowledge with HTTP 2xx and ignore unknowns safely. For operation status meanings, see Operation lifecycle.
Sandbox API base: https://raas-widgets-backend-sandbox.up.railway.app
Use this to persist the link and deliver url to your user asynchronously.

user.created

Fired the first time RaaS Widgets creates a User for your referenceId (typically on magic-link claim). source is one of claim, request_money, deferred_payout_bind, terms_accept, debug, or system. Correlate later events with userId / referenceId. Money movement still uses operation.*.

user.role_added

Emitted once per role the first time the user participates as sender (funded / created an operation or deferred origination) or receiver (minted a money request or claimed a deferred payout). Optional correlation fields: operationId, requestId, originationId, linkId. Roles are additive history, not entitlements — they do not skip CIP.

user.data_request

Fulfill with:
Details: Data requests.

user.cip_verified

CIP approved. No document or biometric PII is included — use GET /partner/users/:userId if you need CIP outcome detail. Also emitted: user.cip_failed (cipStatus: "failed") and user.cip_manual_review (cipStatus: "manual_review") with the same shape.

operation.created

requestId is included only when the operation fulfills a money request (fund-request / Request API). Direct send operations omit it. Deferred payout claims include originationId instead.
After create, the operation moves through createdprocessing → a terminal status. See Operation lifecycle.

operation.completed

Treat this as final success for fulfillment and reconciliation.

operation.failed

If you held balances or locks on operation.created, reverse them when you receive operation.failed.

operation.cancelled

Widget-initiated cancels may include referenceId and cancellationReason. Corridor-driven cancels include funding/payout/amount and may include requestId when the op fulfilled a money request. There is no separate operation.expired event — funding expiry maps to cancelled.
If you held balances or locks on operation.created, reverse them when you receive operation.cancelled.

request_money.created

Emitted after a successful legacy POST /v1/request-money. The platform creates a money request and a fund-request link for the sender.
Persist requestId and deliver fundRequestLink to the sender. Later operation.* events for the same ask include the same requestId. Full journey: Request money lifecycle.

request_money.failed

Emitted when a legacy Request API POST or GET under /v1/request-money fails (for example identity / watchlist rejection at create).
request_money.updated is deprecated and not emitted. For payer fulfillment and settlement, use operation.created, operation.completed, operation.failed, and operation.cancelled.

deferred_payout.created

Emitted when a deferred payout origination is created (legacy deferred-payout API or first persistence in an awaiting-claim / payment-bound state).
See Deferred payout.

deferred_payout.updated

Same payload shape as deferred_payout.created. Fired when binding state or operationId changes (claim, cancel, expire, or operation sync) after the initial create notification.

deferred_payout.failed

Structured error payload when a deferred payout API call fails (path, method, error code, HTTP status, message) — same pattern as request_money.failed.

Handler sketch

Next steps

Security

Verify HMAC signatures.

Operation lifecycle

Statuses and which webhooks fire.

Request money lifecycle

Request → fund-request → operation.

Data requests

Fulfill user.data_request.