Idempotency

important idempotency keys are not applicable to marketplace lending (arix) users for arix, duplicate protection is built into the compliance engine to help prevent double funding idempotency support our system supports idempotency to retry requests without the risk of performing the request multiple times this is especially useful in situations where there is a network outage, and you aren’t sure if a previous request has been processed successfully with an idempotency key, a unique value generated by the client, our server recognizes subsequent retries of the same request this guarantees that retrying a request with the same idempotency key doesn't result in another execution of the endpoint how it works in api design, idempotency ensures that making the same request multiple times results in the same outcome as making it once this is especially useful in scenarios where a client retries a request due to a network timeout or an uncertain response idempotency saves 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 idempotency key return the same cached results of the original request, including errors for example, if a client sends a request to deposit a check or initiate a payment, an idempotent api prevents the operation from being processed more than once—even if the client resends the same request by using an idempotency key, clients can safely retry requests without worrying about unintended side effects like duplicate transactions this helps improve reliability and user experience in distributed systems where intermittent failures are expected key generation the idempotency key is not permanently saved in our system a previously processed request is determined by a duplicate value in the combination hash of user client id from the token, uri endpoint, idempotency key , and request body if the request body is modified in any way and re sent, it won't be seen as a duplicate request and is processed normally therefore, if the intent is to process the request a second time, the idempotency key should be changed to a new value any duplicated or matched submissions are rejected idempotency keys are eligible to be removed from the system automatically after they're at least 24 hours old, and a new request is executed 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 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 this is because no api endpoint began execution it is safe to retry these requests server side our server has an idempotency middleware this middleware checks each of the requests coming into the application to see if the idempotency key is present in the headers if the idempotency key is present in the request, it queries the database to check if there’s a record corresponding to that idempotency key if there is, the middleware stops any further execution in the middleware layer itself, and immediately responds with the saved data as a response otherwise, it continues to the application layer and creates a new record in the database with the idempotency key and the generated response, and finally return the same response to the client a previously processed request is determined by a combination of same endpoint, request body and idempotency key if the request body is modified in anyway, it will not be seen as a duplicate request and will be processed normally unique key every time a request is made with an idempotency key, the server saves resulting status code because it is a unique value, the server uses that information to recognize subsequent retries of the same request post requests all post requests accept idempotency keys make sure to include a unique key in your request to protect against accidental duplicate requests put, get and delete requests put, get and delete requests are naturally idempotent and there is no value in adding an idempotency key the key is ignored if present in these requests idempotent requests to perform an idempotent request, you must provide an idempotency key xxxxx in the header curl request post \\ url https //sandbox crbcos com/rtp/v1/payments \\ header 'accept application/json' \\ header 'content type application/json' header "idempotency key xxxxxx" \\ how to check if a request is idempotent you can detect if a request is being handled as a duplicate and returning a cached response by looking for the original request id response header if an original request id value appears in the response header, it means the request has been handled as a duplicate the original request id value correlates to the cr generated request id of the original request processed under the idempotency key provided important the idempotency key isn't searchable use the clientidentifer field in the request payload to have a transaction unique, searchable id if you use both the clientidentifer and the idempotency key , ensure that the clientidentifer doesn't automatically refresh if it does, the idempotency key hash check will appear unique (even if the idempotency key is the same), and allows the transaction to process as unique