Developer docs
Retries and idempotency
Every read can be repeated safely. When a change fails without an answer, for example on a timeout, the table says whether sending it again can do it twice. Where it cannot, simply send it again. Where it can, read the current state first, then decide. The API takes no idempotency key.
| Operation | Call | Safe to repeat |
|---|---|---|
| Add a transfer | POST /transfers | Yes |
| Archive a transfer | POST /transfers/{uetr}/archive | Yes |
| Change a webhook endpoint's address | PATCH /webhooks/{id}/url | Yes |
| Add a webhook endpoint | POST /webhooks | No: read first |
| Delete a transfer | DELETE /transfers/{uetr} | Yes |
| Delete a webhook endpoint | DELETE /webhooks/{id} | Yes |
| Invite a teammate | POST /team/members | No: read first |
| Re-check a transfer now | POST /transfers/{uetr}/recheck | No: read first |
| Remove a teammate | DELETE /team/members/{member_id} | Yes |
| Rename a transfer | PATCH /transfers/{uetr}/label | Yes |
| Resend a team invitation | POST /team/members/{member_id}/resend | No: read first |
| Restore an archived transfer | POST /transfers/{uetr}/restore | Yes |
| Rotate a webhook signing secret | POST /webhooks/{id}/rotate-secret | No: read first |
| Send a test event | POST /webhooks/{id}/test | No: read first |
| Set a transfer's check frequency | PATCH /transfers/{uetr}/check-frequency | Yes |
| Share a payment record | POST /transfers/{uetr}/record-share | No: read first |
| Correct a transfer's details | PATCH /transfers/{uetr}/details | Yes |
| Change a webhook endpoint's events | PATCH /webhooks/{id} | Yes |
Adding a transfer is safe to repeat: adding a UETR the account already holds returns that transfer and uses no more of the plan. A delete or a removal that already went through changes nothing more when sent again, and answers not_found, or seat_not_active for a teammate. An add sent while the same archived transfer is being restored or deleted can be refused with transfer_archived; send it again. A refusal of the request itself, such as rate_limited, invalid_request or active_transfer_limit, means nothing was done; follow its Retry-After where there is one. temporarily_unavailable and request_failed mean the outcome is not known, as with a timeout: for a change that is not safe to repeat, read the current state before sending it again. See rate limits.