Table deposits

Records a deposit you collected outside Tablezio for a large booking (cash, transfer, phone), then applies it to the bill, refunds it or marks it forfeited after a no-show. To have guests pay a deposit online when they book, use the reservation widget with your Stripe account.

In the platform, Table deposits is the table-deposits module, served under /table-deposits, with 10 HTTP routes (4 GET, 1 POST, 5 PATCH) — /table-deposits is the one you will hit first. Of those, 6 routes write, so the module is not a read-only report bolted onto someone else's data — it owns its records and the rest of the platform reads them. It belongs to “Front of house”, one of the ten functional areas Tablezio is organised into.

It earns its keep hardest in fine dining, which is where the workflow it replaces is usually the most manual. Because it runs on the same account, the same locations and the same guest and order records as everything else, there is no nightly sync to babysit and no second login to buy: the reason to replace three subscriptions with one platform is that the third one stops disagreeing with the other two about what happened yesterday.

Inside “Front of house” it sits next to Digital reservation book for restaurants, Reservation widget, Digital waitlist for restaurants, and those share its records rather than copying them — the reason the category works as a unit and not as three products that happen to be sold together.

Table deposits is driven from the Tablezio interface rather than from the public REST API — the public API covers orders, menu, reservations, customers, loyalty, inventory, analytics, financial reports and webhooks, and this module is not one of them. If you need it programmatically, a webhook on the events it produces is usually the shorter path. See how it fits a whole operation on the fine dining page. Which plan includes it is listed on the pricing page: the free plan covers the digital menu, and each paid plan states exactly which modules come with it.