Request idempotency

Robaws protects you against creating duplicate resources in a failure-retry scenario by using idempotency keys. If you send the same request twice with the same key, the operation is executed only once and you get the original response back. See the Robaws API article for the general API basics.

Sending an idempotency key

Provide your own client-generated key using the Idempotency-Key header. The value must be unique for your user/client id and can be max 128 characters long.

POST https://app.robaws.com/api/v2/work-orders
Authorization: XXX
Idempotency-Key: 8f14e45f-ea4c-4f7a-9a1b-2c3d4e5f6071

Idempotency keys are only supported for PATCH, POST and PUT. You may send the header with other HTTP methods, but it will be ignored. Keys are scoped per tenant and per user, so two users can safely use the same key value.

How the response is replayed

We always return the original response for the same idempotency key, but only if the request succeeded (no 400 or 500 occurred). When the response comes from the cache, we add the header x-robaws-idempotency-cached-response: true so you can tell a replay apart from a fresh call.

Failed requests are never cached. If the first call returned a 400 or a 500, a retry with the same key executes the operation again.

Concurrent requests

If you fire multiple concurrent requests with the same idempotency key, you may receive a 409 CONFLICT. Serialise your retries, or wait for the first response before retrying.

Questions about your integration? Mail support@robaws.com.

Bijgewerkt op: 28/08/2026