The API: what it's for
What this covers
What the API lets you build, and who this section of the knowledge base is for. Requires the
API Access feature on your plan and the manage-settings permission to manage
keys.
Who this is for
Not for everyday restaurant work — nothing here is needed to run a service. This section is for whoever builds things for you:
- Your website developer, putting a booking form on your own site
- Your POS or till integrator, keeping bookings and orders in step
- Whoever runs your CRM or mailing list, wanting your guest data
- An in-house developer building a dashboard or a report you cannot get otherwise
Send them this section. If you are not technical, the useful thing to know is that the capability exists and roughly what it can do — the rest of this article tells your developer where to start.
What it enables
| You want to | The API gives you |
|---|---|
| Show bookings in another system | Read reservations, with filters |
| Take bookings on your own website form | Check availability, then create a reservation |
| Keep a CRM in step with your guest book | Read and write guests |
| Drive a kitchen screen or a till | Read orders, advance order and item status |
| React the moment something happens | Webhooks, rather than polling (link Webhooks) |
| Move a booking through service from another app | Confirm, arrive, seat, complete, no-show |
The basics for a developer
- Base URL:
/api/v1 - Authentication: an API key sent as a bearer token (link API keys)
- Format: JSON in, JSON out
- Scope: everything is confined to one restaurant — the key determines which
Start here: the discovery endpoint
GET /api/v1/meta needs no authentication at all and returns the API version,
the base URL, how to authenticate, and a link back to the reference. It is the right first request — it
confirms the API is reachable before any key is involved.
{
"version": "v1",
"base_url": "https://.../api/v1",
"auth": "Bearer token — obtain from Settings → API Keys",
"docs_url": "https://.../help/api-reference"
}Then check the key works
GET /api/v1/ping does need a key, and returns the restaurant it resolved to
plus the plan name. That makes it the ideal second request: it proves the key is valid and confirms
which restaurant it belongs to before anything is written.
{ "status": "ok", "tenant": "The Old Bell", "property_code": "oldbell", "plan": "Professional" }If those two requests work, everything else is detail (link API reference).
Everything is scoped to your restaurant
A key identifies one restaurant, and that is enforced at the boundary rather than left to the caller. There is no way to read another restaurant's data with your key, and no parameter that widens the scope.
The practical consequence for a developer: no tenant or restaurant identifier is sent on requests. The key supplies it.
What the API cannot do
Worth knowing early so nobody designs around something that is not there:
- No settings. Operating hours, booking rules, notification toggles and branding are not exposed — those stay in the app.
- No staff or user management.
- No billing.
- No reports. No endpoint returns the analytics figures; build them from the reservation data (link Exporting report data).
- Tables are read-only. You can list them, not create or change them.
- Waitlist is not exposed as a resource, though you can be notified of waitlist events by webhook.
Rate limits and plan limits
Requests are limited per minute, and the allowance comes from your plan — 60 a minute unless your plan sets more. The monthly booking limit applies to bookings created through the API exactly as it does in the app (link API keys).
Webhooks: the other half
The API is how you ask. Webhooks are how Tabledoo tells you — a request to your server the moment a booking is created, changed or cancelled. For anything that needs to react promptly, webhooks are the right tool and polling is the wrong one (link Webhooks).
Webhooks need the Webhooks feature, which is separate from API Access. You can have either without the other.
Good to know
Keys are not tied to a person. An API key belongs to the restaurant, so a key keeps working when the member of staff who created it leaves — which is convenient and also why you should revoke keys deliberately (link Editing and removing staff).
The API respects your data, not your permissions. A key is not a role; it carries its own scopes, set when you create it.
Changes made by API are real changes. A booking created through the API appears on your Timeline, counts in your reports, and sends the guest the same messages as one typed in by hand.