Handle Idempotency-Key in requisition create/status change endpoints


All requisition create/status changes endpoints (initiate, submit, authorize, reject.. etc.) should handle an optional Idempotency-Key request header. If the Idempotency-Key is provided, the backend must validate that the request with the same key has not been used yet (in order to avoid creating or updating the resource twice). If the request with the given key has already been received we should return 409 Conflict HTTP status code with a meaningful error message. Additionally, if that request has already been completed successfully (meaning the resource was created/updated) the Location header in the response should be set to point to the created/updated resource. An Idempotency-Key should be a v4 UUID. Once used Idempotency-Key should not be available for the next 24 hours (meaning it should return 409 as specified above).

Acceptance criteria:

  • Create/Status changes endpoints (such as initiate, submit, authorize, reject, etc.) should all support optional "Idempotency-Key" request header

  • The Idempotency-Key request header is optional and the requests continue to work if it's not provided with the request

  • The Idempotency-Key is a v4 UUID

  • If the Idempotency-Key has already been used a 409 Conflict status code is returned with a meaningful error message

  • If the Idempotency-Key has already been used and the request has succeeded the Location response header is set to point to the created/updated resource

  • The same Idempotency-Key can only be re-used after 24 hours

  • An idempotency key is checked after authorization checks have passed (that is, if I don't have rights for the resource, I'm getting 403, no matter if the idempotency key has been used or not)

Implementation notes

  • Consider using Redis in-memory database to manage idempotency keys (this is not a requirement)


Mateusz Kwiatkowski


Sebastian Brudziński



Time tracking