Idempotent Requests

The 1099Policy API checks every request header for an an additional Ten99Policy-Idempotent-Key. We use this field to perform an idempotency check to avoid duplicate transfers in case of network failures or timeouts. For example, if a request to create a contractor fails to return a response due to a network connection error, you can retry the request with the same idempotency key to guarantee that no more than one contractor is created.

1099Policy'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.

We suggest using V4 UUIDs, or another random string with enough entropy to avoid collisions.

Keys expire after 24 hours, so a new request is generated if a key is reused outside of that time frame. Results are only saved if an API endpoint started executing. You can safely retry requests that fail validation or conflicts with another request that was executing concurrently.

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.