v1/transfers
OAuth scope: organization.read
Webhook that delivers events related to SEPA transfers.
Supported events:
created— The transfer was created. Fires for transfers initiated outside your integration, and for each execution spawned by a recurring transfer.processing— The account balance was debited and a transaction was created. Can last several hours until the transfer is sent on the network.settled— The transfer was sent to the network. Permanent status.declined— The transfer was declined.data.declined_reasonindicates why. Permanent status.canceled— The transfer was canceled by a user. Permanent status.
Events are delivered for the same transfers that GET /v2/sepa/transfers returns. The recurring
transfer resource itself is not covered here — subscribe to v1/recurring-transfers for that.
Deliveries are not deduplicated, so treat them idempotently: an unchanged transfer being saved again can re-deliver the event matching its current status.
created— The transfer was recorded. Fires for transfers initiated outside your integration, and for each execution spawned by a recurring transfer.processing— The account balance was debited and a transaction was created. Can last several hours until the transfer is sent on the network.settled— The transfer was sent to the network. Permanent status.declined— The transfer was declined.data.declined_reasonindicates why. Permanent status.canceled— The transfer was canceled by a user. Permanent status.
data mirrors the payload of GET /v2/sepa/transfers/{id}, so you can upsert the transfer locally without a follow-up request. data.transaction_id links the transfer to its ledger transaction, letting you reconcile against the v1/transactions topic.
Events are delivered for the same transfers that GET /v2/sepa/transfers returns. The recurring transfer resource itself is not covered here — subscribe to v1/recurring-transfers for that. Individual executions of a recurring transfer are delivered on this topic, with data.recurring_transfer_id set.
Deliveries are not deduplicated. Treat them idempotently: an unchanged transfer being saved again can re-deliver the event matching its current status.
Authorizations
The signature header follows the format t={timestamp},v1={signature}.
Verification steps:
- Extract the timestamp and signature from the signature header
- Reject the request if the timestamp is older than 5 minutes
- Recreate the signed payload: '{timestamp}.{raw_request_body}'
- Compute HMAC-SHA256 of the signed payload using your webhook secret as the key
- Compare the computed signature with the one in the header
Body
Webhook payload for topic v1/transfers. Events: created (transfer recorded, including each execution of a recurring transfer), processing (balance debited, transaction created), settled (sent on the network, permanent), declined (see declined_reason, permanent), canceled (canceled by a user, permanent).
Response
Webhook received successfully