No. Re:amaze has no native, purpose-built integration with Resy, and no restaurant booking system appears anywhere in its integration list. This is also the most closed pairing in the whole comparison, and that is a fact about Resy rather than about Re:amaze. Resy runs no self-serve developer portal, publishes no OpenAPI specification and is not on Zapier. Access is limited to approved partners under a direct agreement.
The short answer
Re:amaze can collect a Resy-bound enquiry from email, chat, SMS or a DM and give it an owner and a status. It cannot act on it inside Resy. Checking the book, releasing a table, adding the guest's note or putting somebody on the notify list all still happen by hand, in Resy, by a person.
Re:amaze + Resy | |
|---|---|
Native integration | None |
Best available workaround | A custom build, and only if Resy grants partner access |
What the workaround still can't do | Check availability, create or amend a booking, or read the guest's Resy history |
The workaround line matters more here than anywhere else in the matrix. For most pairings the honest answer is "a bridge is possible and it is not worth much." For Resy the honest answer is that a bridge may not be possible at all. Resy's partner programme covers point-of-sale, CRM, loyalty, marketing and discovery platforms, and a support helpdesk is not among them. The only publicly available surface is the embeddable "Book with Resy" widget, which lets a guest book from your website and gives a helpdesk no way to read or write anything.
What actually happens to a booking enquiry
Give Re:amaze the credit first, because for a Resy-type restaurant it lands well. In-demand restaurants get a lot of inbound from people who could not get what they wanted online, and that inbound arrives everywhere: Instagram DMs, WhatsApp, the chat widget, the reservations mailbox. Re:amaze pulls all of it into one queue with an owner and a response time, cheaply. For a small team fielding that volume, it is a real improvement.
Here is one enquiry, all the way through.
A DM arrives from a guest who missed the online release, asking to be told if anything opens for two on Saturday and whether the bar counter is walk-in. Re:amaze queues and assigns it.
An agent opens the conversation and reads it.
The agent opens Resy in another tab, because Re:amaze cannot see the book.
They check Saturday for any two-tops, look at whether the notify list is already long, and confirm the current walk-in policy for the counter that night.
They add the guest to the notify list manually, or make a note to watch for a cancellation, re-keying the name and the party size.
They switch back to Re:amaze and reply on the DM.
They close the conversation, or leave it open as a reminder, which means it now sits in the queue as noise.
A cancellation appears on Thursday. Nothing tells the agent, because Resy and Re:amaze do not talk. The table goes to whoever is watching the app, and the guest who asked first hears nothing.
Step eight is the specific loss in this pairing. The enquiry was not mishandled and the reply was fast. The opportunity evaporated because the two systems have no shared memory, and the person who could have matched the cancellation to the request had moved on to other work. One operations director described the inbox behind this workflow as "a black hole, no KPIs, no response rate, nothing."
The wider cost is familiar. 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." For an in-demand restaurant the loss is rarely a single big booking. It is a steady drip of guests who asked, waited, and stopped asking.
What Re:amaze actually connects to
Re:amaze's integration list tells you who it was built for: Shopify, BigCommerce, Magento, WooCommerce, WordPress, Stripe, Google Workspace, Slack, Jira, Aircall, JustCall, RingCentral and Pipedrive, plus Zapier. More than 5,000 e-commerce brands across more than 100 countries use it, and it is rated highly on the Shopify and BigCommerce app stores.
No restaurant booking system appears there, which is consistent rather than surprising. Re:amaze is built and priced for e-commerce businesses, and a reservation-led restaurant is not the customer it was designed around.
What makes this pairing distinct is the other side. Re:amaze has a Zapier connector and a documented API, so it is the more open of the two by a wide margin. Resy has neither a public developer portal nor a Zapier listing, and its integrations are negotiated partnerships rather than self-serve connections. So the usual sentence about a bridge being possible but limited does not apply cleanly here. A bridge requires Resy to agree to one, and Resy's partner categories do not include customer-service software.
Re:amaze's AI drafts replies, summarises threads and powers chatbots, and much of that suite has carried a beta label. It is a real feature set, less mature than the AI in more expensive platforms, and grounded in past conversations and help-centre content. It can draft a warm reply about the notify list. It cannot see the notify list.
One more gap matters for a group. Re:amaze can manage multiple businesses in one place, which sounds like multi-venue support. It divides brands rather than the availability behind them, and it reports on conversations rather than covers, so there is no view of which restaurant is converting its overflow demand and which is losing it.
Why this matters for booking enquiries
A support conversation and a booking enquiry look alike and behave nothing alike. A support conversation is resolved by a reply. A booking enquiry is resolved only when a table is held. For an in-demand restaurant the gap is widest of all, because most inbound is about availability that does not exist yet, and answering well means watching for it to appear.
Re:amaze answers the message. It cannot watch the book. Every request that depends on a cancellation, a release or a notify list ends up depending on a person remembering, which is not a system.
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 one multi-channel queue that still treats every site the same.
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 Re:amaze 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. Re:amaze reports on conversations, response times and volume per channel, 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 not live, and Resy's closed API is the reason it sits where it does. That is the honest status. Restaurants run an email-only pilot now, which already delivers the inbox value shown above: location-aware routing, instant acknowledgement, AI-drafted replies, high-value enquiries surfaced and held for a person, and reporting by location. 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."
Because much of this demand arrives from the network and from third-party sites, automating third-party booking emails is the most relevant read next, and shared inbox software for restaurants is the wider category view. To see what the AI would have said to a real enquiry your team received last week, book 20 minutes.
Frequently asked questions
Does Re:amaze integrate with Resy?
No. Re:amaze has no native integration with Resy, and no restaurant booking system appears in its integration list. Resy is the more closed of the two: it runs no self-serve developer portal, publishes no OpenAPI specification and is not on Zapier, so there is no bridge to build unless Resy grants partner access. Its partner categories cover point-of-sale, CRM, loyalty, marketing and discovery, not customer-service software.
Does Resy have a public API or a Zapier app?
No to both. Access is restricted to approved partners under a direct agreement, and the only publicly available surface is the embeddable "Book with Resy" widget, which lets guests book from your website but gives a helpdesk no way to read or write to your book. That is why this pairing is more closed than most in this comparison.
Is Re:amaze a good choice for a reservation-led restaurant?
It is a fair, affordable answer to scattered channels, and in-demand restaurants have that problem, with overflow demand arriving by DM and WhatsApp constantly. It is a poor answer to booking enquiries. It is built and priced for e-commerce businesses, it has no line into Resy and no prospect of one, and it has no concept of which venue an enquiry belongs to.
What do Resy restaurants use instead for booking enquiries?
Most run a shared inbox next to Resy and accept that every enquiry is handled twice, because no general-purpose helpdesk 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.
