Skip to content
tourpingotourpingotourpingo developers

Retries and idempotency

A request can time out after the API has done its work. Before sending one again, know what a second copy does.

Request Sent twice
Any GET Safe: reading changes nothing.
POST /v1/public/quotes Safe: a quote books nothing.
POST /v1/public/checkout Safe: the same hold with the same lead email books once. The second answer is the same booking, with booking_token and contact_token null.
POST /v1/public/bookings/{ref}/cancel Safe to detect: the second is 409 Conflict. Read the booking to see it is cancelled.
POST /v1/public/bookings/{ref}/contact-changes/{id}/confirm Safe: a used code again changes nothing.
POST /v1/public/holds Not safe yet: a second hold holds the places again.
POST /v1/public/enquiries Not safe: the seller may get the message twice.

Holds

Section titled “Holds”

There is no Idempotency-Key on the public API yet; retry protection for holds is coming with issue #461. Until then:

  • Keep the hold’s ref in the traveller’s session and check it out, rather than holding again, while hold_expires_at hasn’t passed.
  • If a hold times out with no answer, hold again: the lost one gives its places back when its 15 minutes are up.
  • GET /v1/public/holds/{ref} says how a hold stands, expired once its time is up.

Checkout

Section titled “Checkout”

Because the same checkout books once, retry it after a timeout with exactly the same body. Keep the tokens from the first answer that reached you: a repeat carries none, and the traveller can still open the booking with the reference and their email.