Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.debitdirect.io/llms.txt

Use this file to discover all available pages before exploring further.

The API supports idempotency for safely retrying requests without accidentally performing the same operation twice. When creating or updating an object, use an idempotency key. Then, if a connection error occurs, you can safely repeat the request without risk of creating a second object or performing the update twice.
To perform an idempotent request, provide an additional Idempotency-Key: <key> header to the request.

​
Handling Idempotency

Our idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeded or failed. Subsequent requests with the same key return the same result, including HTTP result of 208.
We require the idempotency key to be a unique value generated using V4 UUIDs to avoid collisions.

​
Keys

Keys are eligible to be removed from the system automatically after they’re at least 4 hours old, and a new request is generated if a key is reused after the original has been pruned. The idempotency layer compares incoming parameters to those of the original request and errors unless they’re the same to prevent accidental misuse.

​
Results

Results are only saved if an API endpoint started executing. If incoming parameters failed validation, or the request conflicted with another that was executing concurrently, no idempotent result is saved because no API endpoint began execution. It is safe to retry these requests.

​
Acceptance

All POST requests accept idempotency keys. Sending idempotency keys in GET and DELETE requests has no effect and should be avoided, as these requests are idempotent by definition.