No. Front has no native, purpose-built integration with Resy, and Resy is the hardest booking platform in this category to bridge, because it publishes no public API and is not on Zapier. Front is a collaborative shared inbox and customer-operations platform. Resy is a reservation, waitlist and guest-CRM platform owned by American Express, used by restaurants where the diary is the scarce resource. Front will organise the enquiry beautifully and cannot touch the book.
The short answer
Front can receive a Resy enquiry as a conversation. It cannot do anything with it in Resy. Checking the book, holding a table, reading the guest's history, adding a note: all of that still happens by hand, in Resy, by a person.
Front + Resy | |
|---|---|
Native integration | None |
Best available workaround | A custom build, and only if Resy grants you partner API access |
What the workaround still can't do | Check availability, create or amend a reservation, read the guest's Resy history |
This is the one cell where Front's own openness makes no difference, because the constraint is entirely on the Resy side. Resy runs no self-serve developer portal, publishes no OpenAPI specification, and is absent from Zapier. Integration access goes to approved partners in defined categories (point of sale, CRM, loyalty, marketing, discovery) under a direct agreement. The only public surface is the embeddable "Book with Resy" widget, which is a booking button for your website, not a way for an inbox to read your diary.
What actually happens to a booking enquiry
Front's strengths make the gap sharper rather than softer. It is genuinely good at the inbox part: shared visibility, assignment, internal comments beside the message, SLA rules and response-time reporting. A group running bookings through Front has solved accountability. It has not solved booking.
Here is the real journey of one enquiry when Front and Resy do not talk to each other.
A hotel concierge emails on behalf of a guest, asking whether a table for four can be found for tonight, ideally around 8pm, and mentions the guest is a regular at your other site. The message lands in the shared inbox as a Front conversation.
An agent picks it up and reads it.
The agent opens Resy in another tab, because Front cannot see the book.
They check tonight for four, look at whether any holds are due to release near 8pm, and search the guest's name to see the history the concierge referred to.
They create the booking in Resy, re-keying the guest's name, the concierge's contact details, the time and the note about the sister site.
They switch back to Front and write the reply.
They archive the conversation.
The concierge replies within the hour: "Guest now wants six and 8.30." Six at 8.30 is a different question entirely. The agent repeats steps 3 to 7.
Every enquiry is handled twice, in two systems, by a person copying the same fields between screens. Same-day concierge requests are the sharpest version of this, because the whole exchange has to happen inside an hour and every round trip costs several minutes of tab-switching. One operations director described the inbox behind this workflow as "a black hole, no KPIs, no response rate, nothing," because the work happened in tabs and conversations that no report could see.
The sharper cost is the enquiry you never hear about again. A concierge with a guest waiting will email three restaurants and book whichever answers first. A roughly 40-venue entertainment group lost a single booking worth £40,000 because the enquiry arrived outside working hours and nobody replied in time. A three-site pizza group put it more bluntly about a 30 to 40 cover enquiry: "It just sat there. No one saw it. They went somewhere else." Front did not cause those losses. Routing bookings through a system that cannot book anything is what makes the delay inevitable.
What Front actually connects to
Front is the most interesting case in this comparison, because it cannot be accused of ignoring verticals. Its App Store carries more than 160 integrations, with dedicated categories for logistics and maritime and for travel, built for a customer base in freight forwarding, shipping and travel operations. Front is entirely willing to build deep, industry-specific connections. It has chosen freight over hospitality. Search the App Store for Resy and you will find nothing.
The usual fallback does not exist here either. Front's Zapier integration is solid, with one caveat worth knowing: it can only reach shared inboxes, because the OAuth token is scoped that way, so enquiries in an individual mailbox need a Front API token and Webhooks by Zapier instead. None of that matters when the other end is missing, and Resy is not on Zapier at all.
That leaves a custom development project against Front's API and Resy's partner API, which first requires Resy to grant partner access for a use case that does not match its published partner categories. For most operators the project ends at that conversation. Even if it did not, what you would build is a pipe that copies enquiry text into a conversation, one direction, treating a reservation request as a message. Front AI is a capable suite: Copilot drafts and answers from past conversations, help content and connected systems, Autopilot resolves routine requests, and Smart QA and Topics analyse the queue. All of it is grounded in conversations and knowledge. Copilot can write a warm reply to the concierge. It cannot look at tonight's book.
One planning note: Resy is currently absorbing Tock's venues under American Express, roughly doubling its library to more than 25,000 restaurants.
Why this matters for booking enquiries
A support conversation and a booking enquiry look similar and behave nothing alike. A support conversation is resolved by a reply. A booking enquiry is only resolved when a table is held in the book. That difference is the whole problem.
The shared inbox can write a polished reply. It cannot book the table. The transaction, the part that actually earns the cover, still lands on your team, one enquiry at a time. Front gives you the best-organised version of the old workflow: everyone sees the enquiry, everyone knows who owns it, and the booking still gets typed into another system by hand.
What it looks like when the tool is built for booking enquiries
The gap closes when the inbox and the diary are the same surface, so the enquiry is answered and booked in one place instead of two. This is what RevVue does, and it is easier to show than to describe.
Enquiries are tagged to the right venue as they arrive, so a group with several restaurants stops triaging by hand. That matters more when demand is high, because the enquiries that arrive by email are usually the ones the online book already turned away. The team works from one queue, by location, rather than tags standing in for venues.

One queue, sorted by venue, for the enquiries that never fitted into the online book.
The AI drafts the reply in that venue's voice, using its menus, its policies and the answers it gives most often. Guests who write after missing a slot want a real answer about alternatives, and the draft already contains them.

A drafted reply in the venue's voice, ready for the team to approve or adjust.
Because it connects to the booking system, the AI does the step Front cannot: it checks availability and prepares the booking inside the conversation. Everyday requests are handled on arrival, and the high-value ones, the celebration tables and the large parties, are acknowledged instantly and held in a queue the team works.

High-value enquiries acknowledged and prepared, waiting for a person rather than for attention.
And because every enquiry is tracked by venue, you can finally see the demand that never made it into the book. Response rates, volumes and conversion by site: the part a reservations platform cannot show you. Front reports on conversations and response times, which never connects a reply to a seated table.

Enquiry volume, response rate and conversion by location, including the demand the book never recorded.
An honest note on where RevVue is today
RevVue's Resy integration is on the roadmap, and the honest position today is an email-only pilot. That pilot already delivers the inbox value shown above: location-aware routing, instant acknowledgement, AI-drafted replies, high-value bookings surfaced, and reporting by location. The direct booking-system connection will deepen that when it lands, but it does not gate the value you get today. The UK AI is in pilot.
This is the move the Brasilia Group made, off a horizontal helpdesk and onto an inbox built for the job. Their founder, Nikolaos Kiosses, put it plainly: "The transition from Zendesk to RevVue has been a game changer."
The wider category view is in shared inbox software for restaurants, and if you are consolidating from Tock, the same question applies there: does Front integrate with Tock. To see what the AI would have said to a real enquiry your team received last week, book 20 minutes.
Frequently asked questions
Does Front integrate with Resy?
No. Front has no native integration with Resy, and no restaurant booking system appears in the Front App Store. Resy publishes no public API and is not on Zapier, so a bridge requires partner API access granted directly by Resy plus custom development. Even then it only copies enquiry text into a conversation. It cannot check availability, create a reservation, or read the guest's Resy history.
Can I connect Front and Resy with Zapier?
No. Front is well supported on Zapier, though its integration can only reach shared inboxes because of how the OAuth token is scoped. That is academic here, because Resy is not on Zapier at all. There is no zap to build, and no self-serve API either, which leaves a direct partnership agreement plus custom development as the only route.
Why does Front integrate with logistics and travel tools but not booking systems?
Because Front has picked its verticals and hospitality is not among them. Front's App Store carries dedicated categories for logistics and maritime and for travel, reflecting a strong base of freight, shipping and travel-operations customers. That shows Front will build deep vertical integrations when it decides a market matters. It has not made that decision for restaurant booking systems.
What do restaurant groups use instead for booking enquiries?
Most run booking enquiries through a shared inbox and accept the double-handling, because no horizontal tool solved the booking side. A purpose-built option is RevVue, which is location-aware and whose AI checks availability and prepares the booking inside the conversation. Its Resy integration is on the roadmap, with an email-only pilot available now.


