Idempotency

Accidentally sending a request twice can cause duplicates and errors. To avoid such situations, Treezor recommends you add a unique identifier to your POST and PUT requests using the accessTag attribute.

The accessTag parameter is a string with a maximum length of 250 characters for you to use in accordance with the best practices to generate unique identifiers in your development environment. Here are tips for java (opens new window), npm (opens new window), and php (opens new window) for instance.

Information – The accessTag values are only kept for 24 hours

Therefore, it's not a permanent solution to reconcile Treezor objects to your local database objects. To reconcile objects, use the persistent object tags.

Examples with idempotency

User creation

Let's take an example in which you send a User creation request with an accessTag. The following occurs:

• Treezor receives the request and creates the user.
• You do not get an answer from Treezor, or the request times out on your side.
• You reasonably send the User creation request again.
• Treezor receives the new request, identifies it as a duplicate (same accessTag), and returns the previously created User object.

Money transfer

Let's take an example in which you send a Transfer request from a Wallet to another Wallet with an accessTag. The following occurs:

• Treeezor receives the Transfer request and moves funds to the other Wallet.
• You do not get an anwser from Treezor, or the request times out on your side.
• You reasonably send the Transfer request again.
• Treezor receives the new request, identifies it as a duplicate (same accessTag), and returns the previously created Transfer object.

Examples without idempotency

User creation

Let's take an example in which you send a User creation request without any idempotency accessTag. The following occurs:

• Treezor receives the request and creates a user.
• You do not get an answer from Treezor, or the request times out on your side.
• You reasonably send the User creation request again.
• Treezor receives the new request, handles it as a different request and attempts to create the same user a second time.

Alert – This situation returns an error

Duplicate users are not allowed, using an accessTag would have prevented this situation.

Money transfer

Let's take an example in which you send a Transfer request from a Wallet to another Wallet without any idempotency accessTag. The following occurs:

• Treeezor receives the Transfer request and moves funds to the other Wallet.
• You do not get an anwser from Treezor, or the request times out on your side.
• You reasonably send the Transfer request again.
• Treezor receives the request, handles it as a different request and transfers the same amount a second time.

Alert – Twice the expected amount is moved

Because the transfer occurs twice, you'll then need to refund the duplicate transfer in order to solve the issue. Using an accessTag would have prevented this situation.