Integration API documentation

Create one API key per restaurant. That key can only read and update bookings for that venue. ePOS should store the key against the matching till / shop so incoming reservations are attributed to the correct restaurant.

• Admin: Restaurants → [restaurant] → Integration
• Restaurant portal: Integration
• Platform-wide keys and partners: Admin → Integrations

Every booking includes origin and restaurant so the till can display the source venue even if one ePOS account connects several restaurants:

origin.platform          = "bookmetable"
origin.restaurant_id     = 1
origin.restaurant_name   = "Annapurna Nepalese"
origin.restaurant_slug   = "annapurna-nepalese"
origin.booking_url       = "https://bookmetable.uk/annapurna-nepalese"
source                   = "bookmetable"

Every venue is assigned a permanent integer when it is created. The first restaurant is 1, the next is 2, and so on. If a restaurant is deleted, that number is never given to another venue.

The same number appears on the Integration tab and in every API payload:

GET https://bookmetable.uk/api/v1/restaurant

{
  "object": "restaurant",
  "data": {
    "id": 1,
    "name": "Annapurna Nepalese",
    "slug": "annapurna-nepalese",
    "booking_url": "https://bookmetable.uk/annapurna-nepalese",
    "table_selection_enabled": false,
    "table_lock_minutes": 15
  }
}

• restaurant.id — permanent number
• restaurant_id and origin.restaurant_id on bookings — the same number

ePOS should store this number against the till / shop. Do not use the old rst_… UUID as the public restaurant id.

Send the restaurant's secret key on every request. Keys start with bmt_live_ and are created on that restaurant's Integration tab. Store them on the ePOS server — not in a public website bundle.

Authorization: Bearer bmt_live_…
Accept: application/json
Content-Type: application/json

Machine-readable catalog: https://bookmetable.uk/api. Version manifest: https://bookmetable.uk/api/v1.

Base URL: https://bookmetable.uk/api/v1

Load the connected restaurant

GET https://bookmetable.uk/api/v1/restaurant

data.id is the permanent restaurant number shown on the Integration tab.

List today's bookings

GET https://bookmetable.uk/api/v1/bookings?date=2026-09-21&status=confirmed

Find a guest by phone or name

GET https://bookmetable.uk/api/v1/bookings?phone=07123456789
GET https://bookmetable.uk/api/v1/bookings?q=Alex

Load one booking

GET https://bookmetable.uk/api/v1/bookings/BK-SYF8GG

Mark seated from the till

PATCH https://bookmetable.uk/api/v1/bookings/BK-SYF8GG
Content-Type: application/json

{ "floor_status": "seated" }

Cancel with { "status": "cancelled" }.

Pull the floor plan

GET https://bookmetable.uk/api/v1/areas

Check if Outside Table 6 is free at 19:30

GET https://bookmetable.uk/api/v1/tables/availability?date=2026-09-21&time=19:30&party_size=2

Tell BookMeTable a walk-in sat at a table

POST https://bookmetable.uk/api/v1/tables/status
Content-Type: application/json

{ "epos_table_id": "T6", "date": "2026-09-21", "time": "19:30", "status": "occupied" }

Every list item, detail response, and webhook uses the same JSON shape so a web ePOS can show guest name, contact details, covers, time, notes, visit state, and which BookMeTable restaurant the booking came from. restaurant_id is that venue's permanent number (not a UUID).

{
  "object": "booking",
  "data": {
    "id": "bkg_8f2c1a",
    "reference": "BK-SYF8GG",
    "restaurant_id": 1,
    "restaurant": {
      "id": 1,
      "name": "Annapurna Nepalese",
      "slug": "annapurna-nepalese",
      "booking_url": "https://bookmetable.uk/annapurna-nepalese"
    },
    "origin": {
      "platform": "bookmetable",
      "restaurant_id": 1,
      "restaurant_name": "Annapurna Nepalese",
      "restaurant_slug": "annapurna-nepalese",
      "booking_url": "https://bookmetable.uk/annapurna-nepalese"
    },
    "guest": {
      "name": "Alex Guest",
      "email": "alex@example.com",
      "phone": "07123456789"
    },
    "party_size": 4,
    "covers": 4,
    "date": "2026-09-20",
    "time": "19:30",
    "starts_at": "2026-09-20T19:30:00",
    "timezone": "Europe/London",
    "status": "confirmed",
    "floor_status": "pending",
    "visit_completed": false,
    "special_requests": "Window table, nut allergy",
    "area": { "id": "area_outside", "name": "Outside" },
    "table": { "id": "tbl_6", "number": "6" },
    "lock_at": "2026-09-20T19:15:00",
    "lock_minutes": 15,
    "source": "bookmetable",
    "created_at": "2026-09-19T12:00:00.000Z",
    "updated_at": "2026-09-19T12:00:00.000Z"
  }
}

Fields: id, reference, restaurant_id, restaurant.id, restaurant.name, restaurant.slug, restaurant.booking_url, origin.platform, origin.restaurant_id, origin.restaurant_name, origin.restaurant_slug, origin.booking_url, guest.name, guest.email, guest.phone, party_size, covers, date, time, starts_at, timezone, status, floor_status, visit_completed, special_requests, area.id, area.name, table.id, table.number, lock_at, lock_minutes, source, created_at, updated_at.

Restaurant profile fields from GET /restaurant: id, name, slug, booking_url, source, timezone, opening_time, closing_time, max_party_size, slot_minutes, active, address, city, postcode, phone, table_selection_enabled, table_lock_minutes.

Each restaurant can turn on guest table selection (Tables tab) and name areas such as Outside, Upstairs, and Downstairs with numbered tables. BookMeTable and ePOS stay in sync like this:

1. Floor plan. Configure areas/tables in BookMeTable, or push the till layout with PUT /areas (include epos_area_id / epos_table_id so later updates match).
2. Guest books a table. The booking webhook includes area, table, starts_at, and lock_at (seating time minus lock_minutes, default 15).
3. ePOS locks the table. At lock_at, the till should reserve that table so walk-ins cannot sit there. You can also poll GET /bookings?date=… and lock any booking whose lock_at has passed.
4. Walk-ins and blocked tables. When the till seats a walk-in or marks a table out of service, POST /tables/status with occupied or blocked. BookMeTable will not offer that table. Send free when it is cleared.
5. Availability check. Before confirming a booking or a walk-in, call GET /tables/availability. A table is unavailable if BookMeTable already has a reservation or ePOS has posted a hold.

Push the till floor plan

PUT https://bookmetable.uk/api/v1/areas
Content-Type: application/json

{
  "replace": false,
  "table_selection_enabled": true,
  "table_lock_minutes": 15,
  "areas": [
    {
      "name": "Outside",
      "epos_area_id": "out",
      "tables": [
        { "number": "6", "epos_table_id": "T6", "seats": 4 }
      ]
    }
  ]
}

Use floor status for the on-site workflow. Booking status (confirmed / cancelled) is separate.

pending → arrived → seated → completed (or no_show).

Allowed values: pending, arrived, seated, no_show, completed.

Register a webhook URL on the restaurant connection. BookMeTable POSTs a signed JSON body when subscribed events occur: booking.created, booking.updated, booking.cancelled, booking.completed.

Verify HMAC-SHA256 of {timestamp}.{raw_body} using your webhook secret.

• X-BookMeTable-Signature
• X-BookMeTable-Timestamp
• X-BookMeTable-Event
• X-BookMeTable-Delivery

The webhook data object matches the REST booking object above.

• 401 — missing or invalid API key
• 404 — booking not found for this restaurant
• 400 — invalid JSON or floor_status
• 503 — Integration API disabled platform-wide

Successful JSON responses include X-BookMeTable-Api-Version: v1. Browser tills may call the API cross-origin (CORS + OPTIONS).

• v1 r6 (2026-09-21)
  • Documented permanent numeric restaurant id on GET /restaurant and all booking payloads.
  • Public docs and FAQ updated: restaurant.id / restaurant_id / origin.restaurant_id are integers and are never reused.
• v1 r5 (2026-09-21)
  • Restaurant id is now a permanent number (1, 2, 3…) assigned in creation order and never reused after delete.
  • API restaurant.id, restaurant_id, and origin.restaurant_id use that number instead of rst_… UUIDs.
• v1 r4 (2026-09-20)
  • Areas and tables: GET/PUT /areas, GET /tables/availability, POST /tables/status.
  • Booking payload includes area, table, lock_at, and lock_minutes so ePOS can lock the table 15 minutes before seating.
  • Restaurant profile reports table_selection_enabled and table_lock_minutes.
• v1 r3 (2026-09-20)
  • Per-restaurant Integration tab: each venue has its own API key for ePOS.
  • Booking payload origin + restaurant.booking_url so the till knows which restaurant the booking came from.
• v1 r2 (2026-09-20)
  • Web EPOS booking payload: id, restaurant name/slug, covers, starts_at, visit_completed.
  • Look up a booking by reference or internal id; search list by phone or q.
  • Filter list by floor_status. CORS + OPTIONS for browser-based tills.
  • Restaurant portal amend/cancel now emit booking.updated / booking.cancelled webhooks.
• v1 r1 (2026-06-30)
  • Initial Integration API release.
  • REST: restaurant, bookings list/detail, PATCH floor_status.
  • Webhooks: booking.created, booking.updated, booking.cancelled, booking.completed.
  • Auto contract sync on database migration.