We understand, integrators can write client code in such a way that there can be duplicate requests coming to our platform APIs. These duplicate requests may be unintentional, as well as intentional sometimes (e.g. perhaps, due to timeout or network failture). To keep it balanced, we are currently ensuring processes to make our APIs fault-tolerant so that duplicate requests do not leave the system unstable. You can make idempotent calls any number of times without concern that the server creates or completes an action on a resource more than once. You can retry idempotent calls that fail with network timeouts or HTTP 5xx status codes for as long as the server stores the ID. Idempotency enables you to correlate request payloads with response payloads, eliminate duplicate requests, and retry failed requests or requests with unclear responses. By default, POST and PATCH are not idempotent APIs. However, you may force Idempotency on these APIs by using the X-Request-Id request header, which contains a unique user-generated ID for the client that the serverrs stores for a certain time window.
Not all APIs supports this header. To find out if your API support it and how long the server stores this Request ID, see the reference of the API you are integrating.
For example, when you include a previously specified X-Request-Id header in a request, Superpool returns the latest status of the previous request that used that same header. Similarly, when you omit the X-Request-Id header from a request, the platform duplicates the request.

​
Example

curl -v -X POST https://dev.superpool.unyte.africa/v1/policies/afc01e2c-ed2c-4657-bb24-b4b9a6bc655c -H 'Content-Type: application/json' -H 'Client-Key: d980ab02-ce46-4d1c-a6b7-839d3904fafe' -H 'X-Request-Id: ed33b218-5d30-40b7-b366-fbe23001d4b8' -d '{
    {
        "some_field": "some_value",
        "do_something": {
            "something": "OKAY"
        }
    }
}'
if this requests succeeds, Superpool returns the latest status of the request, which is [] and a JSON response body. 
{
    "id": "489d7b80-aa26-49ee-a545-d7e5be076972",
    "status": "Some Status Message",
    "additional_information": {
        "maybe_not": true
    }
    "links": []
}

​
Additional information

  • The provided X-Request-Id must be unique for each request and API call type. For example, do NOT use the same request ids for purchase policy and authorize policy purchase (coming soon)
  • The platform requires you to provide a valid UUID for the X-Request-Id value.

​
Still facing an issue?