Cookie Policy

In short: Cookies are small text files stored in your browser. We also use similar technologies such as localStorage and session storage. This policy covers all of them. localStorage and session storage are just other small stores your browser keeps on your own device — like cookies, but they are not sent to other websites.

We use cookies and similar storage technologies to keep you signed in, remember your preferences, understand how the Services are used, and protect against fraud. Some are set by us directly; others are set by trusted third-party providers we embed to run the Services (such as Stripe and Cloudflare).

We group cookies and similar storage by what they are for. A cookie in any category may be set by ResoFlow directly or by a third-party provider we embed.

• Essential — required for the Services to function: keeping you signed in, processing payments, protecting against fraud and automated abuse, and remembering the preferences that make the dashboard work the way you left it (such as timeline zoom level, view filters, or which collapsible sections are open). You cannot opt out of these and the Services will not work without them. They include the storage used by our cookie-consent tool itself.
• Analytics — help us understand which pages and features are used so we can improve the platform. These are non-essential: we do not set them until you accept analytics cookies through the consent banner.

Our consent banner therefore offers two controls: essential cookies (always on, because the Services cannot run without them) and analytics cookies (off until you accept). For clarity, the list in the next section still breaks the always-on essential cookies into Essential andFunctional sub-groups by what each one does — but both are part of the single always-on essential category and neither can be switched off separately. (Your consent banner labels this always-on category “Necessary” — the same thing this policy calls “Essential”.)

We do not use advertising or cross-site tracking cookies. We do not run advertising campaigns, build advertising profiles, or sell your data.

Rather than list every internal storage key, we group what we use by what it is for. Names may change as we develop the platform and as third parties update their products.

Essential

These are required for the Services to work, so they cannot be switched off. We use them to:

• Keep you signed in — your dashboard, staff portal and customer “My account” sessions (set by us and by Google Firebase Authentication; mostly stored in your browser's localStorage rather than as cookies).
• Process payments and prevent fraud — cookies set by Stripe on the pages that take a payment (the booking page, event-ticket checkout, gift card purchase, at-table Order & Pay, payment-request links and billing screens).
• Protect against bots and automated abuse — cookies and short-lived challenge tokens set by Cloudflare (including its Turnstile widget) and Firebase App Check.
• Remember your cookie choices — a first-party cookie named cc_cookie (set by our own self-hosted cookie-consent tool and kept for about 6 months) so we don’t ask again. Your choice is stored only in your browser and is not sent to any third party.
• Remember a paired staff-portal device — a first-party cookie named resoflow_portal_device (limited to the /portal path and kept for about a year) so a staff device that has been set up doesn’t need re-setup on each visit. This is a security measure and is not shared with anyone.
• The same paired-device proof is also kept in that device’s localStorage as resoflow.staffPortalDeviceToken (a copy of the cookie above, so a version of the staff portal installed to the device’s home screen can see it too). It is a security measure, is never used to track anyone, and is removed when the venue revokes the device.
• Deliver alerts to a device that has turned them on — when a member of staff (or an owner) turns on push alerts on a device, the browser installs a small ResoFlow “service worker” whose only job is to show those alerts (it never caches pages or intercepts requests), and Firebase Cloud Messaging keeps that device’s push token in the browser’s own storage (an IndexedDB database named firebase-messaging-database). The device also keeps a small record named resoflow.pushDevice in localStorage (which venue, and a one-way fingerprint of its token) so it knows alerts are on. All of it is removed when alerts are turned off or the person signs out; a device that has not been used for 60 days is removed automatically.
• Return to an alert after signing in — if you open a push notification and need to sign in first, resoflow.pendingPushClick in that tab’s session storage remembers its app destination, venue and recipient matching details. It contains no sign-in or device token. You choose when to open it, and we check your current access first. The reminder can be dismissed, stops working after 15 minutes, and is cleared when opened or rejected, when you leave the signed-in app or change account or venue, and when it is next checked after expiry. Closing the tab also ends this session storage.
• Remember that a device said “not now” to the app — resoflow.pwaSetup in the device’s localStorage remembers that the one-time “ResoFlow on this device” card on Home was snoozed (30 days) or dismissed for good on that device. It is a fact about the device, not a person, and can be reset from Settings → Devices and push.
• Remember which venue’s staff portal this device uses — resoflow.lastPortalToken in the device’s localStorage remembers the last staff-portal link used on that device, so a member of staff who signs out lands back on the right PIN screen rather than a generic sign-in page. It identifies the venue’s portal, not a person, and stays on that device only.
• Keep a member of staff signed in to the staff portal — after a successful PIN sign-in, the session (who signed in, their role and which venue) is held in that browser tab’s session storage under staffSession. It belongs to that one tab and is gone the moment the tab is closed or the member of staff signs out.
• Remember you on a venue’s customer pages — when you tick “Keep me signed in on this device for 30 days” in a venue’s customer “My account” portal, a sign-in token is stored in your browser’s localStorage under a per-venue key named resoflow_cprt_<venue> for up to 30 days, so you don’t need a fresh sign-in code each time. The same token lets that venue’s booking and table-ordering pages recognise you. It is a sign-in credential: our servers hold only a one-way hash of it, it is separate for each venue, and it is removed when you sign out or it expires.
• Keep a support conversation on screen after a refresh — when you use the support inbox while signed in to ResoFlow, the conversation being viewed and short-lived links to its attachments are cached in that tab’s session storage under resoflow.supportThread.<venue>.<conversation> and resoflow.supportAttachmentUrls.<venue>.<conversation>, so the chat reappears instantly after a page refresh while the live copy loads. Both belong to that one tab, are cleared when you sign out and are gone when the tab closes; the attachment links themselves expire within the hour.
• Remember an approved display screen (TV) — when a venue sets up a wall-mounted display (for example a bookings board or a waiting-list screen), two values are stored in that device’s localStorage: resoflow.tvDisplayDeviceToken (proof that the venue approved this exact screen — a security measure, like the staff-portal device entry above) and resoflow.tvScreenMode (which board that screen shows). Both stay on the display device only, are never used to track anyone, and are removed when the venue revokes the screen.
• Where a venue splits its Orders screen into kitchen and bar screens, the device’s chosen screen is stored in that device’s localStorage as resoflow.ordersStationRole — which half of the orders a physical pass screen shows. It stays on that device only, is never used to track anyone, and clearing it simply shows everything again.
• When a member of staff taps Assign tables on a booking from a page other than the floor plan, that booking is carried to the floor plan in the tab’s session storage under resoflow.pendingMultiTableSelect so the table picker opens on it straight away. It is taken the moment the floor plan opens and is gone when the tab closes; it is never used to track anyone.
• Each device showing a venue’s Orders screen remembers which layout it shows — Counter, Pass or Wall — as resoflow.ordersLayout, and a device in the Wall layout remembers its dark-or-light choice as resoflow.ordersWallAppearance. Both are facts about that physical screen rather than about a person, stay on that device only, are never used to track anyone, and clearing them simply returns the screen to the Counter layout in the venue’s default colours.
• If a venue puts its Orders screen into full screen, that choice is stored on the device as resoflow.ordersBoardFullscreen — whether the screen at the pass hides the navigation and shows only orders. Like the setting above it is a fact about that screen rather than about a person, stays on that device only, is never used to track anyone, and clearing it simply brings the navigation back.
• A venue’s order screens each remember their own sound choices in that device’s localStorage: resoflow.ordersBoard.sound (how the Orders screen rings for new orders on that screen), resoflow.ordersBoard.readySound (whether that screen plays ready-order alerts) and resoflow.wallPassSound (whether the Orders screen’s Wall layout chimes on that screen). Each is a fact about that physical screen rather than about a person, stays on that device only, and is never used to track anyone.
• Protect booking, ordering and sign-in against abuse — a random value named resoflow.orderDeviceId is stored in your device’s localStorage the first time you use a venue’s online booking, ordering, event, gift-card or customer pages, so our systems can rate-limit unusually high numbers of requests from one device without treating everyone on a shared connection (a venue’s Wi-Fi, a hotel, a mobile network) as one person. It contains no personal information, is never used to track you across sites, and only ever leaves your device as a one-way fingerprint sent with those requests.
• Keep your table order as you build it — where a venue offers Order & Pay at your table, the dishes you add are saved on your device under a per-venue localStorage key named resoflow.orderBasket.<venue>, so your order isn’t lost if the page reloads. It holds your dish selections only (no personal information), expires three hours after your last change, and is removed when you place your order. Ordering for collection or delivery keeps its own separate basket the same way (resoflow.orderBasket.<venue>.remote), under the same three-hour expiry. When a venue offers more than one way to order, the way you chose (to your table, for collection or for delivery) is kept in that browser tab’s session storage under resoflow.orderChannel.<venue> so the Order tab takes you straight back to it during your visit — it holds only that one word, and it is gone the moment you close the tab.
• Spot a sign-in carried onto a different computer — for signed-in venue staff and owners, a small technical description of the device’s hardware (for example its processor core count) is stored in localStorage under resoflow.deviceHardwareStamp. If a saved sign-in later turns up on clearly different hardware (for example after copying everything to a new computer), we sign it out as a security measure. It contains no personal information, never leaves your device, and is never used to track you.
• Recognise a device you’ve signed in from before — for signed-in venue staff and owners, a random identifier is stored in localStorage underresoflow.accountDeviceId so we can tell a device you have used before from a genuinely new one, and only email you about the latter. It is not linked to your hardware, contains no personal information, and is never used to track you.
• Keep a demonstration venue unlocked on your device — if we have personally given you access to a private demonstration venue, a random access value named resoflow.demoAccess.<venue> is stored in your device’s localStorage so the demonstration stays unlocked for you on that device. It works like a door key: it contains no personal information, is never used to track you, and only ever leaves your device to prove to our systems that this device was given access.
• Carry on with your account setup — if we set your venue up with you and you use a setup code, the code is kept on your device under a localStorage key named resoflow.setupCodeResume while the setup is being applied, so a reload or a new tab can pick it back up. It holds the code only (no personal information), expires after two hours, and is removed as soon as the setup finishes. Three session-storage siblings carry the same setup through the current tab only: resoflow.setupCode (the code you entered), resoflow.setupCodeJob (which setup run it started, so a reload reconnects to it) and resoflow.setupCodeHint (that a setup is waiting for your venue, and the venue’s name, so the page can introduce itself). Each is gone when the tab closes or once the code has been used.
• Show a venue’s pages instantly when you move between them — while you use a venue’s public pages (its venue page, booking page, menu, what’s on and so on), the venue’s public details (its name, opening hours, which pages it offers) are kept in that tab’s session storage under resoflow.guestBoot.<page>.<venue>, so the next page paints at once while the live copy loads. It holds the venue’s public facts only — never anything about you — and is gone when the tab closes.
• Skip a loading screen you have already seen — the first venue page you open in a tab shows a brief loading screen; a yes/no marker in that tab’s session storage (resoflow.guestSplashSeen) means later pages in the same tab skip it. Gone when the tab closes.
• Carry a promo code through sign-up — if you arrive at ResoFlow’s own marketing or sign-up pages by a link that carries a promo code, the code is held in that tab’s session storage under resoflow.pendingPromoCode until sign-up applies it. It holds the code only, and is gone when the tab closes.
• Keep your support conversation open — when you start a chat with us on our contact page, your browser tab remembers which conversation is yours and how much of it you have already read. This uses session storage, so it belongs to that one tab and is gone the moment you close it — the next person to use a shared computer never inherits your conversation. The keys are resoflow.publicSupport.v2 (the conversation’s reference, the email address you gave us if you gave one, and a random access value that lets that tab — and only that tab — open the conversation again; a stale entry expires after 90 days), resoflow.publicSupport.pendingAnonToken (that same random access value, saved a moment BEFORE the conversation is created, so that if the connection drops and you try again you carry on in the same conversation instead of starting a second one nobody can reply to), resoflow.publicSupport.seen (how many messages you have already read, so the little unread badge on the chat bubble is accurate), and resoflow.publicSupport.focusedMode (a yes/no marker that you arrived by clicking the link in one of our emails, so the page opens straight into your conversation rather than the marketing page). One further key uses localStorage rather than session storage: if your conversation is passed to a human member of our team before you have given us an email address, its reference and random access value are kept on your device under resoflow.publicSupport.thread for up to 7 days — without an email address, that chat is our only way of reaching you, so closing the tab must not lose your only way back to our reply. It is removed as soon as you give us your email address, decline to, or the conversation is closed.
• Light or dark mode — the appearance you pick for the dashboard, staff portal or admin panel is stored in that device’s localStorage as theme so it opens the same way next time. It is a display preference for that device only and is never used to track anyone.
• Which homepage to show — the public site remembers whether ResoFlow is in normal or maintenance mode as homepageMode in localStorage, so a returning visitor does not see the wrong page flash while the live answer loads. It holds one word and nothing about you.
• Keeping every open tab signed in together — while you use the dashboard, staff portal or admin panel, your last activity time is written to localStorage as resoflow.idleLastActivity.<area> so that a click in one tab keeps your other tabs from signing you out for inactivity. It is a timestamp only, shared between your own tabs on that device, and is cleared when you sign out.
• Customer portal: “add your birthday” prompt dismissed — if a venue’s loyalty scheme offers a birthday gift and you close the prompt asking for your birthday, that choice is remembered on your device as resoflow_cpbday_<venue> so you are not asked again. It stores a yes/no marker only.
• Customer portal: signing out of every tab at once — when you sign out of a venue’s customer portal, a short-lived marker named resoflow_cpsobeacon_<venue> is written to localStorage so any other tab you have open for that venue signs out too. It carries no personal data and is overwritten on each sign-out.

Functional

These remember small interface choices so the Services behave the way you left them — for example whether sidebars are collapsed, your light/dark appearance, your timeline, floor-plan and list view settings, the date and time window you were viewing, which sections you've expanded, and in-app notices you've dismissed. Preference keys are suffixed with an identifier for the signed-in user (for example __user_<id>), so two people sharing a device keep separate preferences. (The “Keep me signed in on this device for 30 days” sign-in token for a venue’s customer pages is a credential, so it is listed under Essential above.)

While you complete a booking on a venue's public booking page, we also temporarily keep the details you've typed into the form (such as your name, contact details and any allergy notes) and, once you've verified it, your email address and the time it was verified, in your browser tab so an accidental refresh doesn't lose them. This stays on your device only, is never shared, and is deleted when you close the tab or complete the booking.

These are all set by ResoFlow in your browser's localStorage or session storage. The exact names may change as we develop the platform; none are cookies, none are analytics, and none are shared with anyone.

Analytics

We also use two cookieless monitoring tools that require no consent because they store nothing on your device:

• Sentry — error tracking and, on the signed-in dashboard and staff portal only, session replay. It sets no cookies. On signed-in screens, when an error occurs Sentry may also save a short replay of the moments around it to help us reproduce the fault. All text, form inputs and media are masked in the replay, so we do not see what you typed. Replay never starts on our public marketing, policy or booking pages; if you move from a signed-in screen to one of those pages in the same browser tab, a replay that is already running may carry on recording there, with the same masking. This is used only to diagnose faults, not for analytics or advertising.
• Cloudflare Web Analytics — page-view counts and page-load timings on our marketing and public pages, added by Cloudflare (the network in front of our site). It sets no cookies, stores nothing on your device and does not track you across other sites; Cloudflare receives the page address, a coarse country and the browser type, and shows us totals only.

Cookies set by third parties on their own domains

We embed third-party services — Stripe (payments, on the booking page, event-ticket checkout, gift card purchase, at-table Order & Pay, payment-request links and billing screens) and Cloudflare Turnstile (bot protection on the booking page, and app-wide as the attestation provider for Firebase App Check). As well as the entries listed above, these providers may set their own cookies on their own domains (for example js.stripe.com or challenges.cloudflare.com). Those cookies are controlled by the respective provider under its own cookie and privacy policy. See our Subprocessors page for links to each provider.

Tracking pixels in emails

Marketing emails sent through the platform contain a small, invisible image (a “tracking pixel”) and tagged links. These are not browser cookies, but they are a similar technology: when the email is opened or a link is clicked, they let the sender see that the email was opened and which links were clicked, so it can measure how the email performed. To avoid this, you can set your email program to stop loading remote images, or use the unsubscribe link in any marketing email to stop receiving them. This does not apply to essential service emails (such as booking confirmations or password resets), which we need to send you.

In short: Analytics cookies are not set until you accept them. You can change your choices at any time through the consent manager, or adjust your browser settings.

When you first visit our public site, our cookie-consent banner asks whether you accept analytics cookies. We do not place any analytics cookies (such as Google Analytics) until you accept — if you ignore the banner or decline, no analytics cookies are set. Essential and functional storage is still used, because the Services cannot work without it.

To change your mind later, click the Cookie Preferences link in our footer. Accepting starts analytics on your next page view; declining stops new analytics data immediately (a page refresh fully clears the analytics tool).

You can also manage cookies in your browser:

• Chrome: Settings → Privacy and security → Cookies and other site data.
• Firefox: Settings → Privacy & Security → Cookies and Site Data.
• Safari: Settings → Privacy → Manage Website Data.
• Edge: Settings → Cookies and site permissions → Cookies and site data.

Disabling essential cookies will prevent the Services from working correctly.

We will update this policy when we add, remove, or change cookies. The "Last updated" date at the top of this page reflects the most recent revision.

For questions about cookies, email [email protected]. For the full privacy picture see our Privacy Policy.