The API supports idempotency for safely retrying requests without accidentally performing the same operation twice. This is useful when an API call is disrupted in transit and you do not receive a response. For example, if a purchase request does not respond due to a network connection error, you can retry the request with the same Client-Request-Id to guarantee that no more than one purchase request is created.
To perform an idempotent request, provide an additional Client-Request-Id: header to the request.
Zip's idempotency works by saving the resulting status code and body of the first request made for any given Client-Request-Id, regardless of whether it succeeded or failed. Subsequent requests with the same key return the same result, including 500 errors.
An Client-Request-Id is a unique value generated by the client which the server uses to recognize subsequent retries of the same request. How you create unique keys is up to you, but we suggest using V4 UUIDs, or another random string with enough entropy to avoid collisions.
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 because no API endpoint began execution. It is safe to retry these requests.
All POST requests accept Client-Request-Id. Sending idempotency keys in GET and DELETE requests has no effect and should be avoided, as these requests are idempotent by definition.
We recommend sending Client-Request-Id for transactional requests only, i.e /purchaserequest and /refund.
To perform an idempotent request, provide an additional Client-Request-Id: header to the request.
Zip's idempotency works by saving the resulting status code and body of the first request made for any given Client-Request-Id, regardless of whether it succeeded or failed. Subsequent requests with the same key return the same result, including 500 errors.
An Client-Request-Id is a unique value generated by the client which the server uses to recognize subsequent retries of the same request. How you create unique keys is up to you, but we suggest using V4 UUIDs, or another random string with enough entropy to avoid collisions.
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 because no API endpoint began execution. It is safe to retry these requests.
All POST requests accept Client-Request-Id. Sending idempotency keys in GET and DELETE requests has no effect and should be avoided, as these requests are idempotent by definition.
We recommend sending Client-Request-Id for transactional requests only, i.e /purchaserequest and /refund.
curl --request POST \
--url https://merchantapi.zipmoney.com.au/v1/purchaserequest \
--header 'authorization: Basic YOUR_API_KEY_ENCODED' \
--header 'content-type: application/json' \
--header 'Client-Request-Id: 1' \