API Overview
The complete, browsable endpoint reference — every parameter, request body, response schema, and behavior note — lives in the interactive API Reference, generated directly from openapi.json. This page summarizes the conventions that apply across the whole API.
Two modules, one credential
Section titled “Two modules, one credential”The RestroLab Third-Party Integration API is a provider-agnostic contract: any external platform (food delivery, booking/OTA, POS, marketplace, etc.) can connect to a tenant’s Restaurant and/or Hotel operations. One credential authenticates both modules — which endpoints actually respond depends only on whether that tenant has the corresponding feature enabled. See Feature gating.
| Module | Endpoints |
|---|---|
| Restro | GET /v1/third-party/menu/, GET/POST /v1/third-party/orders/, GET /v1/third-party/orders/{external_order_id}/, POST /v1/third-party/orders/{external_order_id}/cancel/ |
| Hotel | GET /v1/third-party/hotels/rooms/, GET /v1/third-party/hotels/availability/, GET/POST /v1/third-party/hotels/reservations/, GET /v1/third-party/hotels/reservations/{external_reservation_id}/, POST /v1/third-party/hotels/reservations/{external_reservation_id}/cancel/ |
| Shared | POST /v1/third-party/webhook/ |
| Owner-only | GET/POST /v1/third-party/credentials/, POST /v1/third-party/credentials/{id}/revoke/, POST /v1/third-party/credentials/{id}/rotate/ |
Base URL
Section titled “Base URL”openapi.json does not declare a servers entry. There is one shared API host for every tenant — confirmed from the backend, which resolves the tenant purely from your X-API-Key credential (never from the request’s domain or a header):
https://api.restrolab.com/v1/third-party/TODO: api.restrolab.com above is a placeholder — the real production hostname isn’t in the codebase (it’s an infrastructure/DNS detail) and must be confirmed with RestroLab during onboarding. What is confirmed is that it’s a single shared host, not a per-tenant domain or subdomain.
Authentication
Section titled “Authentication”Two separate mechanisms, for two separate audiences — see Authentication for the full explanation:
- Owner (
/v1/third-party/credentials/*only):Authorization: Bearer <JWT>— their own RestroLab login. - Your platform (everything else):
X-API-Key/X-API-Secretheaders.
API version
Section titled “API version”1.0.0Source: info.version in openapi.json.
Content type
Section titled “Content type”Request bodies are accepted as application/json (also application/x-www-form-urlencoded and multipart/form-data, per the generated spec) — application/json is recommended. All responses are application/json.
Idempotency
Section titled “Idempotency”POST /v1/third-party/orders/ and POST /v1/third-party/hotels/reservations/ are idempotent on external_order_id / external_reservation_id: the first call returns 201 Created, and a retry with the same id returns the existing resource with 200 OK instead of creating a duplicate.
Pagination
Section titled “Pagination”List endpoints use paginated responses. See Pagination for the page, page_size, count, next, previous, and results fields.
Error format
Section titled “Error format”Not yet formally modeled in openapi.json — see Error Handling for what’s confirmed versus still TODO.
Explore the full reference
Section titled “Explore the full reference”The interactive API Reference lets you:
- Browse every endpoint grouped by tag (Third-Party Integration, Third-Party Integration Credentials)
- Inspect parameters, request bodies, and response schemas
- View the full nested schemas (dishes, room types, orders, reservations, credentials)
- Try requests directly from the browser where supported
openapi.json is the single source of truth for endpoint-level detail — this documentation site does not duplicate the endpoint list in Markdown.