Appearance
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, npm, and php 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.