Skip to main content
Each deposit and withdrawal requires a unique, stable idempotency_key permanently associated with a single CRM transaction. For webhooks, event_id serves the same purpose and must have a unique constraint in the receiver.

​
Build the key

Use the immutable identifier of the internal movement:
The key must not depend on the attempt number, retry time, or a random value generated for each request.

​
What to do after a timeout

1

Keep the original payload

Preserve the same user, amount, currency, wallet, reference, and idempotency_key.
2

Retry the same operation

Send exactly the same request. Do not create another logical transaction.
3

Accept the idempotent confirmation

ALREADY_PROCESSED means that the original movement has already been applied and must be treated as successful.

​
Required rules

  • Never reuse a key for another user, amount, currency, or movement type.
  • Do not generate a new key after a timeout.
  • Persist the key before calling ExuraCopy.
  • Record the result and returned transaction_id.
  • Use backoff and a retry limit for transient errors.
  • If a webhook repeats the same event_id, respond successfully without duplicating the account in the CRM.
An idempotency 409 conflict may indicate that the same key arrived with a different payload. Stop automatic retries and investigate the original transaction.

Previous: Account webhooks

Review event delivery and deduplication.

Next: Errors

Handle failed responses consistently.
Last modified on November 3, 2026