SimpleERB Booking API

01 Before you start

Getting your credentials

API access is issued per restaurant by the SimpleERB team. Credentials are not self-service — contact SimpleERB support and ask for API access for your restaurant(s). You will be given:

One set of credentials can be linked to one or more restaurants. Every request that names a restaurantId must name a restaurant linked to your credentials — anything else is rejected with 401 Unauthorized.

02 Authentication

The API uses an OAuth-style resource owner password flow and returns a JWT bearer token.

Step 1 — request a token

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=password&username={API Key}&password={API Secret}

curl -X POST https://book.simpleerb.com/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=password&username=YOUR_API_KEY&password=YOUR_API_SECRET"

Success

{
  "access_token": "eyJhbGciOiJI...",
  "token_type": "Bearer",
  "expires_in": 7200,
  "userName": "YOUR_API_KEY",
  "issued": "...",
  "expires": "..."
}

Invalid credentials

{
  "error": "invalid_grant",
  "error_description": "The user name or password is incorrect."
}

Step 2 — call the API

Send the token on every request:

Authorization: Bearer {access_token}

Token lifetime

Tokens are valid for 2 hours (expires_in = 7200 seconds).

Cache and reuse your token for its lifetime. Do not request a new token per API call — the token endpoint is rate limited, and a token-per-call pattern will lock you out. Keep the token in memory, refresh it when it is within ~5 minutes of expiry, and refresh immediately on a 401.

03 Bookings API

Base path /api/Bookings/v1. All routes require Authorization: Bearer. Request and response bodies are JSON with PascalCase property names.

Common response wrapper

Every Bookings endpoint returns:

Always check IsSuccessFull before reading data.

curl https://book.simpleerb.com/api/Bookings/v1/CheckStatus \
  -H "Authorization: Bearer $TOKEN"

{
  "RestaurantId": 4339,
  "BookingDateTime": "2026-07-20T19:30:00",
  "Covers": 4
}

{
  "IsSuccessFull": true,
  "CallResults": "Timeslot is available for booking",
  "data": true
}

{
  "RestaurantId": 4339,
  "BookingDateTime": "2026-07-20T19:30:00",
  "Covers": 4,
  "Adults": 4,
  "Childs": 0,
  "Infants": 0,
  "CustomerTitle": "Mr",
  "CustomerFirstName": "John",
  "CustomerLastName": "Smith",
  "CustomerEmail": "john@example.com",
  "CustomerPhonePrefix": "+44",
  "CustomerPhone": "7700900123",
  "CustomerPhoneType": "Mobile",
  "CustomerSubscribedToNotifications": true,
  "OfferId": null,
  "SpecialRequests": "Window seat",
  "Notes": "Anniversary"
}

{
  "BookingId": 12345,
  "RestaurantId": 4339,
  "BookingDateTime": "2026-07-20T20:00:00",
  "Covers": 6
}

{
  "BookingId": 12345,
  "RestaurantId": 4339,
  "CancellationReason": "Customer request"
}

04 Restaurant API

Base path /api/Restaurant/v1. All routes require Authorization: Bearer, and parameters are passed on the query string. These endpoints return their payload directly — they are not wrapped in IsSuccessFull / data, except for validation errors, which do use the wrapper.

Dates are passed as yyyy-MM-dd (or a full ISO date-time), and covers defaults to 2 if omitted:

?requestdate=2026-07-20&restaurantId=4339&covers=2

Start here: getBasicInfo

Call this first. It returns the restaurants your credentials are linked to, so you can confirm which IDs to use:

curl "https://book.simpleerb.com/api/Restaurant/v1/getBasicInfo" \
  -H "Authorization: Bearer $TOKEN"

Each entry contains RestaurantUID (the value to send as restaurantId / RestaurantId), Name, address fields, TelNo1, EmailAddress and WebAddress.

Date range limits

To protect response times, ranges are capped:

Dates must fall between 2000-01-01 and 2100-01-01. A request outside these limits returns 400 Bad Request:

{
  "IsSuccessFull": false,
  "CallResults": "Date range must start on or after 2000-01-01, end on or
                  before 2100-01-01, and span at most 92 days.",
  "data": null
}

Split longer periods into several calls.

05 Dates & times

Bookings are stored internally in UTC, but the API speaks restaurant-local time for everything a guest would recognise as a booking time. Audit timestamps stay in UTC.

Values carry no offset suffix (2026-07-20T19:30:00), so treat them as wall-clock times in the zone above rather than parsing them as UTC instants. In practice:

• A slot returned by an availability call can be posted straight back to createBooking unchanged.
• A booking returned by getBookingsForDate shows the same time you booked it for.
• Do not apply your own time-zone conversion to booking times.

06 Rate limits

Limits apply per API user — per calling IP for the token endpoint — in a rolling one-minute window:

Exceeding a limit returns 429 Too Many Requests with a Retry-After header giving the number of seconds to wait.

Recommendations

• Cache your token for its full 2 hours.
• Cache availability results for short periods rather than re-querying per page view.
• Prefer one range call over many single-date calls.
• On 429, wait for the Retry-After interval and retry — do not retry immediately.

07 Errors

Unexpected server errors return JSON:

{
  "IsSuccessFull": false,
  "CallResults": "An unexpected error occurred.",
  "RequestId": "00-4bf92f3577b34da6a3ce929d0e0e4736-01"
}

08 Response reference

RestaurantBookingResponse

Returned by createBooking, modifyBooking, cancelBooking and the booking-list endpoints.

BookingStatus values

Cancelled bookings are flagged by the Cancelled field, not by BookingStatus.

Booking-list response

{
  "startDate": "2026-07-20T00:00:00",
  "endDate": "2026-07-21T00:00:00",
  "RestaurantName": "The Example Kitchen",
  "RestaurantId": 4339,
  "restaurantBookingResponses": [ { "Uid": 12345, … } ]
}

Availability response

{
  "startDate": "2026-07-20T00:00:00",
  "endDate": "2026-07-20T00:00:00",
  "restaurant": { "RestaurantUID": 4339, "Name": "The Example Kitchen", … },
  "availableSlots": [
    {
      "BookingStartDateTime": "2026-07-20T19:30:00",
      "BookingEndDateTime": "2026-07-20T21:30:00",
      "BookingDuration": 120,
      "Covers": 4,
      "MaxCovers": 8,
      "BookingTables": [
        { "AreaId": 12, "AreaName": "Main Restaurant",
          "TableIds": [101, 102], "TableNo": "4" }
      ]
    }
  ]
}

startDate, endDate, restaurant, availableSlots and restaurantBookingResponses are lowercase-initial; all other properties are PascalCase.

09 Typical flow

1. POST /tokenObtain and cache a token.
2. GET /api/Restaurant/v1/getBasicInfoConfirm your restaurant IDs.
3. GET /api/Restaurant/v1/getAvaialbillityForDateShow bookable times to the guest.
4. POST /api/Bookings/v1/isAvailableRe-check the chosen slot at the moment of booking.
5. POST /api/Bookings/v1/createBookingCreate the booking; store the returned Uid.
6. POST /api/Bookings/v1/modifyBooking · cancelBookingHandle later changes.
7. GET /api/Restaurant/v1/getBookingsForDateRangeReconcile bookings into your system.

Go-live checklist

• Token cached and refreshed on expiry, never requested per call
• 429 handled with Retry-After back-off
• 401 triggers a token refresh and one retry
• Booking times sent and read as restaurant-local, with no extra conversion
• Date ranges kept within the 92-day / 366-day caps
• IsSuccessFull checked on every Bookings API call
• RequestId logged from any 500 response
• API Secret stored server-side only

10 Support

For credentials, restaurant IDs, quota changes, or help with a failing request, contact SimpleERB support. When reporting a problem please include:

• The endpoint and full request, with the secret redacted
• The UTC timestamp of the request
• The full response body, including RequestId if present
• Your API Key — never your API Secret