Last updated: 13 October 2026
Each business is walled off
Every record carries the business it belongs to, and the database itself enforces the boundary with row-level security. Each request runs under a restricted database role that can reach only the signed-in business’s rows. A request that doesn’t name a business gets nothing.
On every code change, automated tests try to read and change one business’s data from another, and the build fails if any table is missing the rule.
A customer with a Spice-ey account sees only the orders they placed with the business they’re visiting.
Sign-in and staff access
- Every staff member signs in with their own email and password. We store passwords only as salted, deliberately slow hashes (scrypt), never as text.
- Repeated wrong passwords and code requests are blocked for a while after a few tries.
- Each person has a role, such as owner, manager, cashier, kitchen or accountant, that limits what they can see and do. For example, only roles with customer access can download your customer list.
- Resetting a password signs that person out on every device. Owners remove staff in Console → Staff.
- Customers sign in to storefronts with a one-time code that expires within minutes.
- Connecting an outside AI assistant needs the owner’s password, and the owner can revoke it at any time.
Every change leaves a trail
Sensitive changes in Console are written to an audit log: who did it, what changed and when.
The log is append-only. The database refuses edits and deletions, and each entry is linked by a hash to the one before it. We check the chain every night, and owners can see the log in Console under Team & access → Audit log.
Hosting and backups
- Our database and background jobs run on Railway in Amsterdam, the Netherlands. Our websites and apps run on Vercel, on servers in Frankfurt, Germany.
- Every website and app is served over HTTPS only, and browsers are told never to fall back to plain HTTP.
- The payment-provider keys a business connects are stored encrypted.
- Every night we copy the whole database to a second provider, then restore that copy into a fresh database to prove it works. We keep the seven most recent nightly copies and one from each of the last eight weeks.
Card payments
Card details are typed into the payment provider’s own secure page (Paymob). Full card numbers never reach Spice-ey. Customers pay the business directly, and Spice-ey doesn’t hold merchants’ money.
AI
- AI features run on Anthropic’s Claude models. Anthropic processes the content on our behalf under contract and doesn’t use it to train its models.
- Each feature gets only what it needs. The owner assistant works from totals and counts, not from your customer list.
- Owners check AI drafts before anything reaches customers.
- Outside AI assistants connected through agent access never receive customers’ names, phone numbers or addresses.
How we build
Every change passes automated checks before it reaches production, and those checks can’t be skipped. They include our tests, with the isolation tests above, and a scan for leaked passwords and keys. The open-source code we use is checked for known vulnerabilities whenever it changes, and again every day.
Changes to sign-in, payments, data separation and the database get an extra review before they ship.
Errors are reported to Sentry with phone numbers, emails and addresses masked. The full list of providers that handle data is on our data page.
Certifications
Spice-ey doesn’t hold a security certification such as SOC 2 or ISO 27001 yet. If your company needs a security questionnaire answered, email us and we’ll answer it.
Report a security problem
If you think you’ve found a security problem, email hello@spice-ey.com with “Security” in the subject. We aim to reply within one business day.
While you look into it, please don’t access other businesses’ or customers’ data, disrupt the service or contact our customers, and give us a reasonable time to fix the problem before you share it.
Our contact details are also in our security.txt file.