Privacy policy

ForkPI is operated by Pronto Sage.

For privacy questions or requests to access, correct or delete personal data, contact [email protected].

When you register a restaurant, ForkPI stores the restaurant or group name, the country where it operates, the owner's email address, the chosen interface language, and the version of these documents that was accepted. The workspace then holds what the restaurant configures: venues, tables and areas, service periods, menus, prices, service and pricing rules, and its subscription record.

Each person working in a workspace has an account with an email address, a display name, an interface language, and, for accounts that use one, a password stored only as a salted scrypt hash. An account created through Google has no password stored at all. Where two-factor authentication is enabled we store the encrypted enrolment secret and a record of completed checks, but never the authentication codes.

The workspace also holds each person's roles and permissions, their station or work area, and an operational record of what they did during service, such as which visit they opened, which order they accepted, which dish they delivered, and which bill they closed. This gives the restaurant a reviewable history of its service.

ForkPI does not ask diners to create an account and does not build a profile that follows a diner between visits or between restaurants.

A guest approved to join a table receives an opaque browser credential for that visit. ForkPI stores it only in hashed form. It expires and is revoked when the visit closes. Alongside it we hold what the visit is made of: the items ordered, any notes or allergen selections entered with an order, service requests raised from the table, the interface language used during the visit, and its bill and payment record.

Scanning a table's QR code identifies the table only. It does not allow ordering by itself; a staff member must approve the guest's access to the visit.

A reservation holds the booking and whatever contact detail was supplied with it, typically a name and one contact method. It is the restaurant's data, entered to hold a table. We do not use it for marketing and do not share it between restaurants.

Restaurants upload menu photographs, dish images, logos and, where they use assisted authoring, source documents such as an existing menu PDF. These are stored in ForkPI and used on that restaurant's own ForkPI pages.

When a restaurant enables assisted menu authoring or the guest assistant, the relevant content is sent to the AI provider selected for that feature so it can produce a draft or a reply. If the restaurant does not enable these features, no content is sent to an AI provider. When a restaurant connects the optional guest assistant to a messaging channel, messages exchanged on that channel are processed to answer them.

To keep the service working and accounts safe we record security audit events (who did what, when, and whether it was allowed), authentication outcomes, rate-limit counters, request correlation identifiers, and application logs and metrics.

IP addresses are used transiently for abuse and brute-force protection; where an address is retained beyond the request that carried it, it is stored as a hash. We do not log passwords, session tokens, authentication codes, payment card details, or Google tokens.

ForkPI uses only cookies and browser storage that are necessary for the service. It does not use advertising cookies, analytics cookies or cross-site tracking.

These values keep staff signed in, keep an approved guest connected to the correct visit, protect forms against cross-site request forgery, pair supported terminals, complete Google sign-in safely, and remember the interface language you choose. Authentication and guest cookies use opaque values and are httpOnly where applicable.

ForkPI offers "Continue with Google" as a way to sign in. It is used for authentication, account creation and account linking, and for nothing else. ForkPI requests only these Google OAuth scopes:

ForkPI uses a small number of service providers. Each receives only what its function requires: hosting and infrastructure; transactional email delivery; subscription billing for ForkPI's own fees; Google, when someone chooses to sign in with Google; and optional features a restaurant enables itself (an AI model provider or a messaging platform).

None of them processes diners' payments. ForkPI does not take card payments from diners; see the Terms of service.

Each restaurant's data is isolated from every other restaurant's. This isolation is enforced in the database, not only in application code. Access within a restaurant is limited by role, and sensitive operations are denied when authority cannot be confirmed.

Passwords are stored only as salted scrypt hashes; session, guest and device credentials only as hashes; provider credentials and two-factor secrets are encrypted at rest. Traffic is served over HTTPS. Backups are held off-host and restoration is tested.

Depending on where you are, you may have rights to access, correct, delete, restrict or object to the processing of your personal data, to receive it in a portable form, and to complain to a supervisory authority.

Where ForkPI is the controller (your ForkPI account), write to [email protected]. Where the restaurant is the controller (a reservation you made, an order at a table), ask the restaurant; ForkPI assists it in responding.

Where personal data is transferred outside the country it was collected in, we rely on a lawful transfer mechanism such as an adequacy decision or Standard Contractual Clauses. Hosting region and the current list of subprocessors are available on request.

We update this policy when the service changes. We notify restaurants with ForkPI accounts in advance of material changes. The version and date at the top identify the current text.