Booking lifecycle

A booking over the public API always follows the same three steps: get a binding quote, submit it as a booking, then poll for staff review.

The flow

1. Request a quote. POST /quotes with the asset group and date range returns a binding price, valid for 30 minutes, with a full breakdown.

2. Submit the booking. POST /bookings with the quoteId and customer details creates a pending reservation and returns 202 Accepted. Always send a unique Idempotency-Key header.

3. Poll for status. GET /bookings/{id} returns the current status. Staff confirm or reject pending bookings in the dashboard.

Idempotency

Every POST /bookings request must carry a unique Idempotency-Key (a UUID is ideal). Retries with the same key replay the original response — success or business rejection alike — instead of creating a duplicate booking.

Note

If a request fails before a response is recorded (for example a 5xx), the key becomes retryable within about two minutes. Otherwise a stored response is replayed for 24 hours.

Single-use quotes

A quote can be redeemed exactly once. Concurrent attempts to book the same quote are serialized by a database constraint: one succeeds with 202, the other receives 409 QUOTE_ALREADY_USED.

Error codes you should handle

Status	Code	Meaning
400	VALIDATION_ERROR	Request body or query failed validation.
401	UNAUTHORIZED	Missing or invalid key / session token.
403	ORIGIN_NOT_ALLOWED	Browser origin not in the key’s allow list.
403	QUOTE_SESSION_MISMATCH	Quote belongs to a different session.
404	QUOTE_NOT_FOUND	No quote for this key with that id.
409	QUOTE_EXPIRED	Quote is past its 30-minute window — request a new one.
409	QUOTE_ALREADY_USED	A booking already exists for this quote.
409	REQUEST_IN_PROGRESS	Same Idempotency-Key is currently processing.
429	RATE_LIMITED	Too many requests — back off and retry.

For the complete request and response schemas, see the API Reference.