data object for each event.
operation_created
Emitted after a successful POST /v1/request-money persists a remittance for your partner. The data object is a snapshot of the operation as you would receive it through the public API plus the inbound requestData.
string
required
Stable identifier of the partner that owns the operation.
string
required
Eight-character alphanumeric operation code you supplied on
POST.string
required
Operation identifier. Currently equal to
referenceId.string
required
End-user identifier you supplied inside
requestData.number
required
Amount of the operation, copied from the inbound payload.
string
required
ISO 4217 currency code copied from the inbound payload.
number
required
Validity window of the operation in minutes.
string
required
One of
pending, processing, completed, rejected, cancelled. New operations always emit with pending.string
Human-readable description of
status.string
required
Absolute WhatsApp link generated for the payer.
string
required
Absolute landing-page link generated for the payer.
object
required
The full
requestData you submitted (applicant, address, payout method).string
ISO 8601 instant the operation was first stored.
string
ISO 8601 instant of the most recent persisted change.
operation_created example
operation_updated
Emitted after a successful PATCH /v1/internal/remittances/status for one of your remittances. The data object has the same shape as operation_created; status, statusDetails, and updatedAt reflect the new state.
operation_updated example
operation_error
Emitted when the API throws while handling a request that targets one of your operations. The data object describes both the failing call and the error.
string
required
Stable identifier of the partner that owns the operation.
string
required
HTTP path of the failing call (for example
/v1/request-money or /v1/internal/remittances/status).string
required
HTTP method of the failing call.
string
Operation reference, when discoverable from the request body or URL.
string
required
Stable identifier for the error class. Examples:
OFAC_HIT, BadRequestException, UnprocessableEntityException, ServiceUnavailableException, NotFoundException, Error.number
required
HTTP status code returned to the synchronous client.
500 for non-HTTP errors.string
required
Human-readable description of the failure.
object | string
Structured error body when available — for example the OFAC
restrictionKey or the validation report from the API. Absent for plain Error instances.operation_error example (OFAC hit)
operation_error example (validation)
operation_error fires whenever a handled request raises an exception, including provider failures (for example a transient 503 from the identity validator). It is independent from the synchronous HTTP error your client receives — both happen.Ordering and at-least-once delivery
Events are delivered at least once. Retries reuse the sameX-Webhook-Delivery-Id so your handler can deduplicate. The dispatcher does not guarantee strict ordering across events; if you need a total order on a given operation, key off data.referenceId and break ties with data.updatedAt (or the envelope timestamp for operation_error).