API Essentials

The Restoo API is organized around REST. Our API has predictable resource-oriented URLs, accepts JSON request bodies, returns JSON-encoded responses.

Base URL

Restoo has separate environments:

• Dev — Sandbox environment where you start developing your integration.
• Prod — Live environment for all Restoo accounts.

Each environment has is unique Base URL:

Dev

https://api-dev.myrestoo.net/v3

Authentication

The Restoo API supports two authentication methods:

• Partner API Keys — Used by official Restoo integrations and technology partners.
• User API Tokens — Used by Tenant users to access the API with the same permissions they have in the Restoo platform.

All API requests must be made over HTTPS.

Requests sent over plain HTTP or without proper authentication headers will be rejected.

All requests must include the appropriate credential in the Authorization header using the Bearer scheme.

Partner Authentication

Partner API Keys are unique per Tenant.

Authentication Headers

HTTP Header	Description
Authorization	Static API Key for the Tenant, passed as a Bearer token Bearer <API_KEY>
Restoo-Partner-Id	Unique identifier of your Partner account provided by Restoo.
Restoo-Account-Id	Unique identifier of the Tenant.

Example partner authentication headers

Authorization: Bearer d49a8ae8be824f0ab19990f4b59476bd
Restoo-Partner-Id: your_partner_id
Restoo-Account-Id: best-burger

User Account Authentication

User API tokens are associated with a specific Restoo user account.

A User API token grants access to all Tenants that the user can access through the Restoo platform.

Create a User API Token

Each token is associated with a user and inherits the permissions of that user’s role. For better security, use a dedicated user and assign only the permissions required by your integration.

1. Select the user

   In Restoo, go to Configuration > Users, then select the user that will own the token.

2. Review the user's role

   Check that the selected role grants the permissions your integration needs. If you change the role, click Save before continuing. Then click API Tokens.

3. Generate the token

   Enter a descriptive name that identifies the integration, then click Generate token. Copy the generated token and store it securely.

Treat API tokens like passwords. Do not share them or commit them to source control. If a token is exposed, regenerate or delete it from the user’s API Tokens page.

Authentication Headers

HTTP Header	Description
Authorization	API token generated for the Restoo user, passed using the Bearer scheme: Bearer <USER_API_TOKEN>.
Restoo-Partner-Id	Must always be set to api when using User API tokens.
Restoo-User-Id	Email address of the user who owns the API token.
Restoo-Account-Id	Unique identifier of the Tenant to access. The user must have access to this Tenant.

Example user authentication headers

Authorization: Bearer <USER_API_TOKEN>
Restoo-Partner-Id: api
Restoo-User-Id: [e-mail]
Restoo-Account-Id: best-burger

Authorization

Private properties

Some API objects contain private properties — fields with data intended for internal venue use or for specific authorized integrations.

These fields are only returned when the authenticated partner has the necessary permissions. They are available exclusively to the following integration types:

• Restoo User Account Authentication integrations
• POS integrations
• Host Assistant integrations
• Analytics integrations

Booking Channel integrations do not receive private properties.

JSON only

We use JSON for all API data. The style is no root element and camelCase for object keys.

This means that you have to send the Accept: application/json on all requests, and Content-Type: application/json; charset=utf-8 header when you’re POSTing or PUTing data into Restoo.

i18n

Many resources, including Floor Plan Area and Experience, may have some of the content localized on this supported languages:

Language Code (ISO 639)	Description
ca	Catalan
de	German
en	English
es	Spanish
eu	Basque
fr	French
it	Italian
pt	Portuguese

By default, Restoo returns all localizable resources in the Tenant primary language as defined in the venue settings.

You may include the Accept-Language header in the request to specify the preferred response language. If the resource is not localized in the requested language, the response will default to the Tenant primary language.

Rich text content

Many resources, including Floor Plan Area and experience descriptions, represent their content as rich text in HTML. Rich text content may contain headings, lists, simple formatting, and links.

Time Zones

Requests

Clients MUST send naive local datetimes (no T, no offset) in the tenant’s local time zone.

Restoo interprets all request datetimes according to the tenant’s IANA time zone (e.g., Europe/Madrid). The caller does not need to know the offset or whether daylight saving time is in effect — 20:30:00 always means 8:30:00 PM at the venue.

Responses

All datetime fields are returned in ISO 8601 format with offset (e.g., 2025-03-20T20:30:00+02:00).

Standard Formats

Dates

Following ISO 8601 format.

Type	Format	Example
Date	YYYY-MM-DD	2025-03-20
Time	HH:mm:ss	23:59:59
Date and Time	YYYY-MM-DDTHH:mm:ss+HH:mm	2025-03-20T23:59:59+02:00

Phones

Following E.164 format.

Country	Example
Spain	[phone]
Italy	[phone]
USA	[phone]