Idempotent Requests

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 request to send a notification does not respond due to a network connection error, you can retry the request with the same idempotency key to guarantee that no more than one notification is sent.

To perform an idempotent request, provide an additional Idempotency-Key: <key> header to the request.

cURL

curl --request POST \
     --url https://api.courier.com/send \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'Idempotency-Key: 5de04035-9105-4c76-a6dc-fd20441a5ab9' \
     --data "event=RESET_PASSWORD"
     --data "recipient=AzureDiamond"
     --data "data[resetToken]=7c334d35"

Courier's idempotency works by saving 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 key return the same result, including 500 errors.

An idempotency key 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.

Keys are eligible to be removed from the system after they're at least 24 hours old, and a new request is generated if a key is reused after the original has been pruned.

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 idempotency keys. Sending idempotency keys in GET and DELETE requests has no effect and should be avoided, as these requests are idempotent by definition.

Idempotency Key Expiration

By default, the idempotency key specified will be eligible for reuse after 24 hours. There is no need to manually prune the keys.

The expiration of the idempotency key can be altered by setting a x-idempotency-expiration header value. The value of this header can be either epoch milliseconds or an ISO-8601 formatted date string. The minimum value that can be set is 24 hours. The maximum value that can be set is 1 year.

Note: idempotency key expiration cannot be updated until the original request expires, even if you make a new request is with the same key and different x-idempotency-expiration header value.