The RevasiPartner API.
Your reservations and guests, readable by the CRM and analytics tools your group already runs, and by AI assistants through the MCP server. Read-only keys you create in Settings, a sandbox on demo venues, and an OpenAPI document for every endpoint.
GET /api/v1/reservations?date_from=2026-10-10&date_to=2026-10-10Authorization: Bearer rv_test_••••••••Demo only: sample data and simplified responses. The API reference has every field.
- Get a key.In Revasi, open Settings → API keys and create a sandbox key. It reads only the demo venues.
- Make a request.Send the key as a Bearer token, exactly as in the console above.
- Page through.Pass next_cursor back as ?cursor= until it comes back null.
- Go live.Create a live key for your venue and swap it in. Nothing else changes.
Ask about your reservations in plain language.
Your team asks an AI assistant about the book, and it answers from Revasi: covers, booking sources, returning guests. MCP is the open standard assistants use to work with other software, and Revasi’s MCP server gives an assistant the same read-only access to your reservations and guests as the Partner API. It works today in Claude Code, Cursor and VS Code. The ChatGPT and claude.ai apps need a sign-in flow for this server that Revasi does not offer yet.
Your guests ask assistants too. A second MCP server, with no key, answers “is there a table on Saturday for four?” with the times your booking page offers, each linking to it with that time already chosen, so the guest confirms and pays any deposit with you, under your own brand. It reads availability and nothing else: no reservations, no guest details. Booking sites can ask the same over plain HTTP: revasi.net/api/mcp/public and revasi.net/api/availability.
- No integration to build.The assistant reads what each tool does and calls it when a question needs it. There is nothing to code or host.
- Read-only, by design.It can look at bookings and guests. It cannot create, change or cancel anything on your floor, and private operator notes and dietary details never reach it.
- Your key, your venues.Admins create and revoke keys in Settings → API keys. Each carries the Partner API’s scopes and its 60-a-minute limit, so an assistant only ever sees what its key allows.
- Errors it can act on.Every failure comes back with a code and a hint, so the assistant corrects itself instead of guessing.
How many covers did we seat last Saturday, and how many added the wine pairing?
{
"date_from": "2026-10-03",
"date_to": "2026-10-03",
"status": [
"SEATED",
"PARTLY_SEATED",
"LEFT"
]
}You seated 86 covers across 31 bookings last Saturday. 11 of those bookings added the wine pairing, for 19 guests.
What you can read.
Four endpoints, all read-only, all scoped to the outlets on your key. The MCP server’s tools return the same fields. Structured dietary fields and private operator notes are never exposed.
| Endpoint | Scope | Returns |
|---|---|---|
| GET /api/v1/guests | read:guests | Guests with a booking or waitlist entry at your outlets. |
| GET /api/v1/guests/{id} | read:guests | One guest, with visit history and waitlist entries. |
| GET /api/v1/reservations | read:reservations | Reservations, filtered by date, outlet, status or guest, with updated_since for sync. |
| GET /api/v1/reservations/{id} | read:reservations | One reservation, with attribution, payment, estimated value and upgrades. |
- GET /api/v1/guestsread:guestsGuests with a booking or waitlist entry at your outlets.
- GET /api/v1/guests/{id}read:guestsOne guest, with visit history and waitlist entries.
- GET /api/v1/reservationsread:reservationsReservations, filtered by date, outlet, status or guest, with updated_since for sync.
- GET /api/v1/reservations/{id}read:reservationsOne reservation, with attribution, payment, estimated value and upgrades.