The Check Protect API request supports Idempotency for safely retrying requests without accidentally performing the same operation twice, or creating a new transaction - either due to network interference or communication failures.
An idempotent request is denoted by the clientId + transactionId fields from the API request.
Occurrences such as network issues and timeouts may occur impacting our clients’ ability to receive a response from Ingo Money. In the event clients do not receive a response from their request to Ingo Money, clients may safely retry utilizing an Idempotent request which contains the same clientId + transactionId values as the original request.
If the original request was not received by Ingo, the Idempotent request will be accepted as an original transaction. If the original request was received prior by Ingo, an Idempotent response payload will be returned echoing the most recent score given by the API and should be treated as a success.
An API response will contain a custom header indicating whether the response is idempotent or not.
If a response is idempotent, the following header will be included in the response
X-Idempotent: "true"
If a response is not idempotent, the following header will be included in the response
X-Idempotent: "false"
There might be a scenario where our client sends us the same idempotent request before the original request completes, in this case, the API will respond with 409 Conflict HTTP Status Code and the below response body denoting and "in flight/in progress" transaction.
{
"errorCode": "IN_FLIGHT_TRANSACTION_CONFLICT",
"type": "https://httpstatuses.com/409",
"title": "IN_FLIGHT_TRANSACTION_CONFLICT",
"status": 409,
"detail": "IN_FLIGHT_TRANSACTION_CONFLICT",
"instance": "/deposit/score"
}
Responses where idempotency is true will not produce webhooks.