# Every store's bookings, for your operations desk GET /reservations Select code sampleFetchcURL ```js const url = 'https://data.creatorain.com/partner/v1/reservations?from=2026-09-01&to=2026-09-30&status=pending&acknowledged=false&limit=50'; const options = {method: 'GET', headers: {Authorization: 'Bearer '}}; try { const response = await fetch(url, options); const data = await response.json(); console.log(data); } catch (error) { console.error(error); } ``` ```sh curl --request GET \ --url 'https://data.creatorain.com/partner/v1/reservations?from=2026-09-01&to=2026-09-30&status=pending&acknowledged=false&limit=50' \ --header 'Authorization: Bearer ' ``` - Production (live stores; a live key is issued per partner) - Sandbox, for integration testing (test keys, test stores) The same rows as the per-store list, across every store enrolled under your key, each row also carrying `partner_location_id` and `location_id` so it can be attributed. YOUR “NEEDS FOLLOW-UP” LIST IS THIS CALL WITH FOUR PARAMETERS: ``` GET /partner/v1/reservations?status=confirmed&from=2026-09-11&to=2026-09-12&acknowledged=false ``` Those are the visits arriving that nobody at the restaurant has confirmed seeing, and they are the same bookings `unacknowledged_upcoming` on `GET /summary` counts, so a desk can go from the number straight to the rows. PARTNER KEY ONLY. A store token cannot read this: a merchant’s browser must never be able to read the whole chain’s schedule, which is the reason the per-store credential exists. ## Authorizations - **[partnerApiKey](/partner-api/reference/#partnerapikey)** ## Parameters ### Query Parameters **from** string format: date Earliest VISIT DATE to include, `YYYY-MM-DD` in the store’s own calendar. A value we cannot read is refused rather than ignored: a reconciliation run whose window was silently dropped would read the whole book and report it as one month. #### Example ``` 2026-09-01 ``` **to** string format: date Latest VISIT DATE to include, `YYYY-MM-DD`, inclusive. #### Example ``` 2026-09-30 ``` **status** string Allowed values: pending confirmed rejected cancelled completed no\_show Return only bookings in this state. **acknowledged** boolean `true` for bookings a human at the restaurant has confirmed seeing (you told us so with `POST /reservations/{reservation_id}/acknowledge`), `false` for the ones nobody has. Omit it for both. `1` and `0` are accepted as well. ANY OTHER VALUE IS REFUSED with `400 validation_error` rather than ignored, and that is on purpose: a follow-up list that silently returned every booking would show your desk a queue of work that has already been done. #### Example ```json false ``` **cursor** string The `next_cursor` from the previous page, sent back UNCHANGED. Omit it for the first page. It is opaque: do not build one yourself. It names a POSITION in the sort order rather than a count of rows to skip, which is why a page stays stable when a booking is touched between two requests. A cursor we did not issue is refused with `400 validation_error`, rather than silently treated as the first page, so a broken client fails loudly instead of looping over page one for ever. **limit** integer default: 50 \>= 1 <= 200 Rows per page. Default 50, maximum 200. A larger value is CLAMPED to 200 rather than refused, so you never have to guess the ceiling. ## Responses ### 200 A page of bookings across every store of this key. Media typeapplication/json object **items** required Array