Aller au contenu

Overview

Public reservation & guest API served on api.useservice.app. Authenticate with a restaurant API key as Authorization: Bearer sk_live_....

Every endpoint names the scope it needs, and a key carries only the scopes chosen when it was created.

  • Reads need reservations:read.
  • The guest book (/v1/guests) and the guest expansion need guests:read. So does modification_token, which is expanded only on POST /v1/reservations, for the booking that request creates — no read, list or webhook carries it.
  • Writes need reservations:write. One qualifier scope, reservations:write:override, carries the three powers that place a booking the restaurant’s rules would otherwise refuse: it lets you send the itemised override array, it lets you exempt a booking from the shift limits with excluded_from_shift_limits, and it lets you book a whole room with entire_section_id. A key either has all three or none.
  • GET /v1/ping needs only a valid key.

Every operation below lists every status it can answer with, one exception aside: a 500 is not a contract and is not listed per operation. It is the same envelope as any other error, with type: "api_error" and code: "internal_error", it means a fault on our side rather than anything about your request, and the answer to it is to retry.

Every response — success or error — carries an X-Request-Id header. It is the id to quote when you report a problem: it is how one specific call is found in our logs. Send your own X-Request-Id and we echo it back rather than minting one.

Information

  • OpenAPI version: 3.0.1

Restaurant API key: Authorization: Bearer sk_live_...

Security scheme type: http