Skip to content
Gatehouse

Gatehouse

Privacy policy

Two relationships, and they are not the same. We hold data about venues because they are our customers, and we handle data about ticket buyers because a venue asked us to.

Last updated 20 September 2026

This is a working draft. It describes accurately how Gatehouse is built and how it handles money and data, but it has not yet been reviewed by a lawyer and it is not a substitute for one. If you are relying on it for anything that matters, write to hello@gatehouse.app and ask where the review has got to.

1. Who is responsible for what

This is the structural bit, and everything below follows from it.

For a venue’s own account, we are the controller. You signed up with us, we decide what we need in order to run your account, and this policy is our promise about it.

For the people who buy tickets, the venue is the controller and we are its processor. The buyer’s relationship is with the venue. The venue decides what to collect, what to say to them and how long to keep it; we act on the venue’s instructions and on nobody else’s.

If you bought a ticket and want your data corrected or deleted, the venue that sold it to you is who to ask. If you cannot reach them, write to hello@gatehouse.app and we will do what we can to put you in touch.

2. What we hold about a venue

  • The account: venue name, address, time zone, support address, branding.
  • Each staff member: name, email, role, and a password stored as a scrypt hash at OWASP’s cost parameters. We never hold the password itself and cannot tell you what it is.
  • Sessions: a hash of the session token, the browser’s user agent string, and when it was last used, so you can sign a lost phone out.
  • An audit log of who did what: fulfilments, emails and refunds, against a name and an email recorded as text.
  • Your Stripe account identifier and subscription status. Not your bank details, and not your tax identifiers.

3. What we handle on a venue’s behalf

About a ticket buyer, we store:

  • Their email address, and their name and phone number if given.
  • What they bought, what they paid, and the order and ticket records that go with it, including refunds, exchanges and transfers.
  • When a ticket was scanned at the door, and whether it was admitted or refused, which is what the attendance report is made of.
  • If they add a ticket to Apple or Google Wallet: a device identifier and a push token, so a rescheduled show reaches the pass already in their pocket. Not their name, and nothing else about the device.
  • If they join a waitlist: the address to make the offer to, and their place in the queue.

We never see a card number. Payment happens on Stripe’s own checkout, on Stripe’s systems. What comes back to us is a reference and a status.

4. Addresses, briefly

We record a coarse identifier derived from the connecting address to enforce rate limits on the endpoints that take money or create accounts. It is stored as a counter against a time window, not as a history of who visited what, and the windows are swept away continuously.

5. Cookies

One. It is called gh_session, it is set only when a member of venue staff signs in, and it holds a random token and nothing else. It is HTTP-only, same-site, and secure in production.

There is no analytics, no tag manager, no advertising pixel and no third-party script of any kind on this site or on a venue’s box office. A buyer browsing a calendar is not given a cookie at all, which is why you will not find a consent banner here: there is nothing to consent to.

6. What we never do

  • Sell anybody’s data. To anyone. Ever.
  • Market to a venue’s buyers. The only mail this system sends them is their own confirmation and the notices they opted into.
  • Advertise another venue’s show to them. There is no marketplace in this product to do it on, and adding one would break the promise the company is for.
  • Use one venue’s data to do anything for another venue. Every query in the application is scoped to a single venue, and the database denies everything by default to anything that is not the application.

7. Who else touches it

We use a small number of companies to run the service. Each gets only what its job needs:

  • Stripe processes payments and holds the card and identity details we have no business holding.
  • Supabase hosts the database the application runs on.
  • Cloudflare serves the application and issues the certificates for venue domains.
  • Resend delivers transactional email: confirmations, transfers, waitlist offers.
  • Apple and Google receive the ticket details needed to make a wallet pass, when a buyer chooses to add one.

We will tell venues before adding anyone to that list. We may also disclose data where the law requires it, and where we are allowed to say so, we will tell the venue first.

8. Where it lives, and for how long

Data is stored in the United States. If you are in the UK or EEA, that is a transfer out, and we rely on the standard contractual clauses our providers offer for it.

  • Orders, tickets and scans: kept while the venue’s account is open, because they are the venue’s financial and attendance records.
  • Sessions: 12 hours, which is one shift. Expired rows are swept continuously.
  • Signup handoff tokens: two minutes, one use, deleted the moment they are spent.
  • Rate-limit counters: only as long as the window they belong to.
  • After an account closes: 90 days, so a mistake is recoverable, then deleted.

9. How it is kept

  • Everything travels over TLS.
  • Passwords are scrypt hashes with the cost recorded per hash, so it can be raised without locking anybody out.
  • Session tokens and handoff tokens are stored only as SHA-256 hashes, so a copy of the table is not a set of working credentials.
  • Row level security is on every table with no policies: a deny-all backstop, so the data is unreachable from anything but the application even if a key leaks.
  • Staff accounts lock after repeated failed sign-ins, and sessions are revocable per person and per device.

No system is perfectly secure. If there is a breach affecting a venue’s data we will tell that venue without undue delay, and within the deadlines the law sets where it sets one.

10. Your rights

Depending on where you are, you may have the right to see what we hold about you, correct it, delete it, take a copy elsewhere, or object to some of what we do with it.

Venues: write to hello@gatehouse.app and we will act on it. Much of it you can already do yourself from the box office.

Ticket buyers: ask the venue that sold you the ticket. They are the controller and we act on their instruction. If they pass your request to us, we will act on it promptly.

If you are in the UK or EEA and we have not dealt with you properly, you can complain to your data protection authority. We would rather you gave us the chance to fix it first.

11. Children

Gatehouse is a tool for businesses and is not intended for children. We do not knowingly collect data from anyone under 13. Whether a venue is allowed to sell a particular ticket to a particular person is the venue’s responsibility, and the software supports age limits on an event for exactly that reason.

12. Changes

We will post any change here with a new date at the top, and tell venues about a material one at least 30 days ahead, to the address on their account.

Gatehouse is the data controller for venue account data. Write to hello@gatehouse.app about anything on this page.

Questions about any of this go to hello@gatehouse.app, and reach a person.