v1/recurring-transfers
OAuth scope: organization.read
Webhook that delivers events related to SEPA recurring transfers, meaning the recurring transfer resource itself rather than the individual transfers it executes.
Supported events:
created— The recurring transfer was created.canceled— The recurring transfer was canceled, so no further transfers will be executed from it.
There is no updated event: a recurring transfer cannot be edited in place, so changing one
means canceling it and creating a new one, which you receive as a canceled followed by a
created.
To follow the individual transfers a recurring transfer executes, subscribe to v1/transfers
instead: each execution is delivered there with recurring_transfer_id set to this resource.
Deliveries are not deduplicated, so treat them idempotently: an already-canceled recurring
transfer being saved again can re-deliver canceled.
created— The recurring transfer was recorded.canceled— The recurring transfer was canceled, so no further transfers will be executed from it. Previously, detecting a cancellation made outside your integration required re-listing all recurring transfers.
updated event. A recurring transfer cannot be edited in place, so changing one means canceling it and creating a new one — which you receive as a canceled followed by a created, each carrying its own id.
data mirrors the payload of GET /v2/sepa/recurring_transfers/{id}, so you can upsert the recurring transfer locally without a follow-up request. It carries no status, declined_reason, or transaction_id: those describe the individual transfers a recurring transfer executes, not the recurring transfer itself.
To follow those executions, subscribe to v1/transfers as well. Each execution is delivered there as a created event with data.recurring_transfer_id set to this resource’s id.
Deliveries are not deduplicated. Treat them idempotently: an already-canceled recurring transfer being saved again can re-deliver canceled.
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/recurring-transfers. Events: created (recurring transfer recorded), canceled (no further transfers will be executed from it). There is no updated event, since a recurring transfer cannot be edited in place.
Response
Webhook received successfully