Getting started

Read this once before integrating. It covers the environments, authentication and how a restaurant request moves from submitted to live.

Environments

Env	Base URL	Notes
Sandbox	https://api-sandbox.mozrest.com	What providers integrate against during onboarding.
Production	https://api.mozrest.com	After sandbox sign-off, Mozrest provisions production credentials separately.

Authentication

Mozrest provisions a booking channel token per provider. Pass it on every request:

Authorization: Bearer <token>

The token identifies your channel: every request you create and read is scoped to it. The same token is used for the Booking Channel API once a restaurant is live.

How a request moves to live

1. You create a request with the restaurant name, address, the reservation software it uses and the restaurant's reference in that software.
2. Mozrest matches the reference. When it matches, the restaurant is attached right away; when it does not, the request is still accepted and the reservation software partner resolves it by hand.
3. The reservation software partner activates the restaurant for your channel. Some software asks the restaurant to confirm first.
4. The request reaches live. From then on the restaurant is returned by GET /v1/bc/venues and can be booked.

Status	Meaning
pending	being processed by the reservation software partner, the restaurant or Mozrest
live	bookable through the Booking Channel API
rejected	refused by the reservation software partner, see rejectReason
closed	no longer active

Which reservation software can be requested

Every reservation software connected to Mozrest accepts requests by default. A request is refused with 403 when a software is not available to your channel (see Errors). The list of software codes to use in rms is provided by Mozrest during onboarding.

Forward compatibility

Mozrest may add new fields to response payloads at any time. These additions are not considered breaking changes. Ignore unknown fields and use lenient deserialization.