The API supports Idempotency for safely retrying requests without accidentally executing the same request twice resulting in duplicates. This is especially useful in cases where API requests are disrupted in transit and you do not receive a response. For example if an API request to issue a policy gets disrupted due to a network connection or timeout error, you can retry the request using the same idempotency_key parameter to guarantee that no more than one policy gets issued.
To perform an idempotent request, provide a idempotency_key query parameter to the request.
Root'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. Idempotency keys can be up to 255 characters long.
Keys will be removed from the system automatically after they're at least 12 hours old, and a new request is processed if a key is reused after the original has been pruned. The idempotency layer compares incoming parameters to those of the original request and returns an error 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 because no API endpoint began execution. It is safe to retry these requests.
Currently only POST requests for issuing policies 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.