Skip to main content

Idempotency

To prevent duplicate transactions, double billing, or race conditions during network retries, Yativo supports the standard Idempotency-Key HTTP header on all mutating requests (POST, PUT, PATCH, DELETE).

Idempotency Behavior

  • Key reuse within 60 minutes: Reusing the same Idempotency-Key for any request that already completed within 60 minutes returns HTTP 409 Conflict:
    Generate a fresh Idempotency-Key for every new operation. Retries of an in-flight request should wait for the first call to finish or use the same key only while the first attempt has not yet completed successfully.
  • Payload mismatch: Reusing an Idempotency-Key with a different request payload returns HTTP 409 Conflict:
  • In-flight concurrent request: Sending a duplicate key while the first transaction is still actively processing returns HTTP 409 Conflict:
  • Transient server errors (5xx): 5xx responses are not cached, allowing you to retry the request with the same idempotency key once the network issue clears.
  • Implicit keys: If you do not supply an Idempotency-Key, Yativo automatically computes a cryptographic SHA-256 fingerprint from the request payload to guard against immediate double-submissions.

Rate Limits

Yativo enforces rate limits per account to preserve high availability and platform resilience.

Handling Rate Limits

When your request rate exceeds the threshold, the API responds with HTTP 429 Too Many Requests:
Inspect the Retry-After response header to determine how many seconds to pause before sending your next request. Enterprise accounts can request customized throughput limits.