Security

Every connection to the platform is encrypted with TLS, and browsers are told to use nothing else (HTTP Strict Transport Security). Sessions are encrypted, and the most sensitive fields, such as the payment provider keys a restaurant connects and the secrets behind two-factor sign-in, are encrypted in the database with an application key held outside it. The database, file storage and backups are encrypted at rest by our hosting and storage providers. Passwords are never stored, only a salted bcrypt hash.

Every account can turn on two-factor sign-in with an authenticator app, with one-time recovery codes for a lost phone; our own staff cannot use the platform’s internal tools without it. Sign-in attempts are rate-limited per account and per address, so guessing passwords is slow. Team members can sign out of every other device in one step.

Inside a restaurant, each person has a role (owner, manager, staff and more specific ones) that decides what they can see and change; payment settings, team management and guest data exports are reserved to owners and managers. Our support staff can only open a restaurant’s account through an impersonation that is recorded in the audit log with their name.

Changes that matter are recorded with who made them, when, from which address and what changed: settings, prices, team membership, refunds and voids, payment settings, domains, and every action our staff take inside an account. Owners see their restaurant’s log in the admin. The log is not pruned.

The database is a managed PostgreSQL service with point-in-time recovery, which can restore it to any moment in the last retention period of our database plan. On top of that, a full copy is taken every night and stored in a separate storage bucket with separate credentials; we keep seven daily and four weekly copies. Every month we restore the latest copy into a scratch database and check it, because a backup nobody has restored is not a backup.

Every public endpoint is rate-limited, forms are protected against cross-site request forgery, and every response carries security headers that forbid framing and content sniffing. Guest pages reveal only what the guest needs; order and booking links are unguessable. Errors are reported to our error tracker with passwords, tokens, card data, phone numbers and email addresses removed before they leave the server. Every change is covered by automated tests before it is deployed.

Card details are entered on the payment provider’s own forms and go straight to it; they never pass through or rest on our servers. We do not currently hold a third-party security certification such as ISO 27001 or SOC 2, and we will say so here until we do. Customers who need a security questionnaire answered can ask through the contact page.

If you believe you have found a security problem, write to the contact page with the steps to reproduce it. We acknowledge reports within three working days and keep you informed until it is fixed. We will not take legal action against research done in good faith that avoids harm to guests and restaurants: do not access, change or keep data that is not yours beyond what the proof needs, do not degrade the service, and give us reasonable time to fix the problem before you disclose it. We do not currently run a paid bug bounty.