Written by: JJ Tan, Founder, Jelly | Last updated: 6 November 2026
Key Takeaways
- The Lightspeed OpenTable integration syncs table status, guest details, orders and spend in real time, so front-of-house and the till stay aligned without manual handoffs.
- Successful matching depends on exact table-name parity, a strict 30-minute-before to 60-minute-after seating window, and clear service rules for combined tables and takeout orders.
- K-Series uses the Integration Hub path, O-Series requires the Discover add-on framework, and L-Series needs third-party middleware or a custom API build.
- Most matching failures are fixed by aligning table names, enforcing the seating window and re-authorising OAuth tokens after updates.
- Jelly turns per-diner spend data into live dish-level gross profit, flags supplier price changes automatically and onboards in the first week at a flat £129 per location per month.
What The Lightspeed OpenTable Integration Actually Syncs
The integration keeps reservations and checks in step by syncing key data points between OpenTable and Lightspeed in real time.
- Table opening, when OpenTable triggers a table to open in the POS as soon as a party is seated
- Guest name and notes, so the reservation name and any diner notes appear on the POS check
- Order tracking, with items added to the check visible against the booking
- Table status, with seated, ordering and cleared statuses updating in OpenTable’s floor view
- Guest spend, where the settled check value attaches to the reservation record
- Customer profiles, so spend history accumulates against the guest’s OpenTable profile over time
In service, the host stand and the kitchen see the same table picture, and the guest’s total spend records against their booking without manual entry. The real value sits in the data this creates, once the matching rules are followed consistently in service.
Choosing Your Lightspeed Path: K-Series, O-Series And L-Series
Your setup path depends on which Lightspeed product you run. UK operators most commonly use K-Series, the current flagship restaurant product, or legacy O-Series (Kounta, acquired by Lightspeed in 2019 and now sold as part of the Lightspeed Restaurant line). L-Series has a more limited integration story.
On Restaurant K-Series, you connect through Back Office → Integration Hub → Reservations → OpenTable. This route needs admin-level Back Office access, and table names must match exactly between systems for bookings and checks to join cleanly.
On O-Series (Kounta), the route runs through Back Office → Discover → Integrations → OpenTable. The O-Series API documentation does not reference OpenTable natively. The integration runs through the O-Series add-on framework using OAuth 2.0, so contact Lightspeed support to confirm current UK availability.
L-Series has no documented native OpenTable connector. Operators on L-Series should contact Lightspeed UK support before assuming parity with K-Series. A custom build via the Lightspeed Reservations for Platforms API is the documented route for platform-level reservation connectivity.
UK support routes: Lightspeed markets 24/7 personalised support for UK operators. For OpenTable-side issues, contact OpenTable’s UK restaurant support directly. When troubleshooting a sync failure, open a ticket with both providers at the same time, because faults often sit at the handoff between the two systems.
For a broader view of how Lightspeed performs in practice for UK venues, see the Lightspeed Integration Reviews: Real UK User Experiences guide.
In-Service Matching Rules That Keep Bookings And Checks Aligned
The integration follows fixed matching rules and does not self-correct during service. These rules decide whether a reservation and a POS check match successfully. Breaking any one of them creates the mismatches operators see the morning after a busy service.
The 30-Minutes-Before / 60-Minutes-After Seating Window
OpenTable’s fallback matching logic links a POS check to a reservation only when the table number matches exactly and the check is created no earlier than 30 minutes before the reservation and no later than 60 minutes after it. The primary method uses the POS sending a reservation_id, but the timing rule still applies.
A party seated outside that window will not match, and the cover stays anonymous in reporting. That happens when service runs long, a walk-in takes the table first, or the booking is moved without updating the POS.
Exact Table-Number Parity
The table name in OpenTable’s floor plan must be identical to the table name in the Lightspeed POS, character for character. Mismatched table naming is the most common fixable cause of low match rates, because the join fails immediately when the same table is called “12” on one screen and “T12” or “Patio 2” on the other.
Audit both floor plans before go-live and after any layout change. Keep a single naming convention and apply it across both systems.
Combined Tables And Bar Tabs
Large parties and bar-to-table moves break the one-reservation-to-one-check assumption. Split checks, transferred bar tabs and one check covering two tables all break the matching logic.
Set a clear service policy. Record combined tables under a single table number agreed in advance, and transfer bar tabs to the dining table before the check is closed.
Takeout Orders On Dedicated POS Tables
OpenTable’s POS Integration Setup Guide advises restaurants to open POS checks for to-go, delivery, retail and catering either without a table or on a table dedicated to that purpose. This avoids cross-linking checks with reservations, while still keeping any table numbers used in exact alignment between the POS and OpenTable floor plan.
If a takeout order sits on a table number that OpenTable also manages, it can cross-link with a live reservation and corrupt both records.
Troubleshooting: Why OpenTable Bookings Stop Matching Lightspeed Checks
The issues below are ordered by likelihood, so treat them as a diagnostic sequence. Work through each step before escalating to either vendor’s support team.
- Seating-window breach. Start with the seating window, because it is the easiest to check and the most common cause. If the check was opened more than 30 minutes before or 60 minutes after the booking time, it will not match. Fix this by reseating the party within the window, or by adjusting the reservation time in OpenTable to reflect actual seating.
- Table names do not match exactly. If the timing looks correct, move on to table names. A single character difference between “T12” in Lightspeed and “12” in OpenTable breaks the join immediately. Fix this by aligning both floor plans to the same naming convention and retesting with a live booking.
- Combined tables or transferred bar tabs. When a check moves between table numbers during service, the matching logic loses the link. Fix this by setting a clear service policy for combined covers and enforcing tab transfers before check closure.
- Takeout cross-linking. A takeout order that sits on a table number OpenTable also manages can attach to a reservation by mistake. Fix this by assigning all takeout orders to a dedicated table range excluded from the OpenTable floor plan.
- Version-specific configuration gap. O-Series operators using the add-on framework may find the OAuth 2.0 token has expired or the add-on was not re-authorised after a Lightspeed update. Fix this by re-authenticating the integration in Back Office → Discover → Integrations. L-Series operators should confirm with Lightspeed UK support whether a native connector is available for their account.
- Admin access removed. A staff change can leave the integration running under credentials that no longer have Back Office admin rights. Fix this by reassigning the integration to an active admin account.
For a deeper look at how Lightspeed’s integration layer behaves across UK venues, the Lightspeed Table Booking Integration Guide For UK Venues covers the broader reservation-to-EPOS picture.
Turning Guest-Spend Data Into Margin: Where Jelly Comes In
The Lightspeed OpenTable integration tells you who was in the room and what the table spent. That is useful for service, but it leaves the commercial question open. A full room can still lose money when dishes on those checks are priced against stale ingredient costs.
Connecting reservations to POS transactions shows what a guest spent, but gross revenue and profit are different numbers, and ingredient costs decide the gap. A dish that was profitable last month may be losing margin today because a supplier quietly raised a price.
Lightspeed is the right EPOS for this stack, and OpenTable is the right reservation book. The missing piece is the profitability layer between them. Jelly fills that gap in ways the reservation-to-till link cannot:
- Automatic invoice scanning, with every line item of every supplier invoice scanned so ingredient costs update with each delivery rather than at month-end.
- Live dish-level gross profit, using Jelly’s native Lightspeed integration to pull item-level sales in real time and map them to dishes, so GP per dish stays current. A red percentage flags a dish that has dropped margin, while green confirms it has grown.
- Price Alert, where every supplier price movement is flagged automatically, giving operators clear data to challenge increases and claim credit notes.
- Xero integration, so digitised invoices push to Xero in one click, cutting bookkeeping time by 90%.
- Flat, predictable cost, at £129 per location per month, with no per-user or per-feature charges.
Connecting Lightspeed to Jelly takes approximately five minutes. Open Jelly, go to Integrations, sign in to Lightspeed, grant permissions, then select which POS categories to sync. POS-to-dish linking only surfaces items sold after the connection is made, so the mapping stays clean.
The results are documented. Jelly customers add an average of 2 percentage points to gross margins in the first three months, and cut food costs by 3% over the same period. The gains compound at scale: one operator moved GP from 65% to 72% within 12 weeks on approximately £500,000 in revenue, and Populu lifted GP from 68% to 72% across 16 locations.
The time saving is just as concrete. Menu item costing that previously took 28 minutes in a spreadsheet takes 3 minutes in Jelly, and the invoice-to-dish-costing flow saves operators 10–20 hours of admin per month.
IT complexity and integration overhead are the most significant barriers to back-of-house technology adoption for UK restaurants, which is why Jelly is built to generate initial value in the first week.
If You Need A Custom Build: The OpenTable API Route
Not every operator wants a native path. For operators with development resource who need a bespoke reservation-to-EPOS workflow, such as a multi-site group with a proprietary PMS, Lightspeed publishes a Reservations for Platforms API with 11 operations covering platform onboarding, profile registration and course settings.
O-Series custom builds run against the Kounta REST API using OAuth 2.0 authentication. Both routes require developer time, ongoing maintenance and a clear data model for table-and-time matching. Most UK operators running Lightspeed and OpenTable are better served by the native integration path described above.
Conclusion
The Lightspeed OpenTable integration pays off when three things are true. It must be switched on correctly for your Lightspeed version, with K-Series via Integration Hub, O-Series via Discover and L-Series via a supported middleware route. The matching rules must be held in service, including the seating window, exact table-number parity, combined-table policy and takeout isolation. The per-diner spend data it produces must connect to a margin layer that makes it actionable.
The third condition, a margin layer, is where most operators stop, and it is the one Jelly is built for. Jelly is the best back-of-house profitability platform for Lightspeed OpenTable users because it turns the per-diner sales data the integration produces into live dish-level gross profit, flags every supplier price change automatically, and onboards in the first week at the flat per-location price set out above.
Lightspeed and OpenTable handle the reservation-to-till connection. Jelly handles what comes next.
Frequently Asked Questions
Does OpenTable Work With Lightspeed L-Series?
There is no documented native OpenTable connector for Lightspeed L-Series equivalent to the K-Series Integration Hub path. L-Series operators who need reservation-to-EPOS connectivity should contact Lightspeed UK support to confirm what is available for their specific account configuration.
A custom build via Lightspeed’s Reservations for Platforms API is the documented route for platform-level reservation integration, but it requires developer resource and ongoing maintenance. Most UK operators on L-Series who need a reservation integration are better served by confirming their version with Lightspeed before purchasing OpenTable, or by exploring whether a migration to K-Series is appropriate for their operation.
How Long Does The Lightspeed OpenTable Integration Take To Set Up?
For K-Series, the setup path through Back Office → Integration Hub → Reservations → OpenTable is self-service and typically takes under an hour. Two conditions apply: the operator needs admin-level Back Office access, and table names must already be aligned between the two systems.
The table-naming audit, where every table number in OpenTable’s floor plan matches exactly with the Lightspeed POS, is the step most operators underestimate and the most common source of post-setup matching failures. For O-Series, the path runs through Back Office → Discover → Integrations → OpenTable, and operators should confirm UK availability with Lightspeed support before starting. Allow additional time for testing, and run at least one full service cycle with a test booking before going live.
Why Are My OpenTable Bookings Not Matching Lightspeed Checks?
The most common causes, in order of likelihood, are a check opened outside the 30-minutes-before / 60-minutes-after seating window, table names that differ between OpenTable and the Lightspeed POS, a combined table or transferred bar tab that has split the check across table numbers, a takeout order sitting on a table number that OpenTable also manages, or, for O-Series operators, an expired OAuth 2.0 token that needs re-authorisation.
Work through these in sequence. The majority of matching failures are resolved by correcting table-name parity and treating the seating window as a service standard.
Does Jelly Replace Lightspeed Or OpenTable?
Jelly works alongside both systems. Lightspeed remains the EPOS, OpenTable remains the reservation book, and Jelly sits as the back-of-house profitability layer that connects to Lightspeed via a native real-time API integration.
Jelly pulls item-level sales data from Lightspeed, maps them to dish recipes built from scanned supplier invoices, and produces live gross profit per dish. Neither the EPOS nor the reservation book delivers that view on its own, so the three systems serve distinct functions and are designed to run together.
What Does Jelly Cost?
Jelly charges a flat £129 per location per month. There are no per-user fees, no per-feature charges, and no variable costs tied to transaction volume or number of suppliers. For a multi-site operator, the cost scales predictably with the number of locations.
Onboarding is designed to generate initial value in the first week. Operators gain access to price alerts and spending insights as soon as suppliers begin sending invoices to a dedicated email address, often within 24 hours of the first upload.
