Privacy Policy

NightCount (“NightCount”, “we”, “us”) builds and operates the NightCount service from India. We provide venues with a guest list, a door check-in app, a live view of the night, and a way to ask questions about their own records in plain English; we provide promoters with tracked invitation links and their own guest lists.

NightCount is a sole proprietorship of Rishiraj Guha Ray. NIGHTCOUNT is the registered trade name of that proprietorship. Its principal place of business is R 54 Block 1 Flat 6, Cyberspace Cooperative, Baishnabghata Patuli Township, Kolkata 700094, West Bengal, India, and its GSTIN is 19DBLPG5492K1ZZ. The service is operated from Bengaluru, Karnataka.

A proprietorship is not a separate legal person from the proprietor, so wherever this policy says NightCount is the data fiduciary — for the account data of venues and promoters, as the lede explains — Rishiraj Guha Ray is the individual answerable for it. He is also the grievance officer named in section 9. All correspondence under this policy should be sent to support@nightcount.com.

This policy is governed by the laws of India, and the courts at Bengaluru, Karnataka have exclusive jurisdiction over any dispute arising out of it.

What NightCount holds depends entirely on your role. Each category below is exhaustive for that role as the service is built today.

2.1Venue accounts

To open and run a venue account we collect a business email address used for sign-in (consumer email addresses are refused, so that a venue account can be tied to the business it claims to be), the venue name and city, and the venue’s own configuration for the service: entry types and their prices, door and pricing rules, the hour at which the venue’s night is treated as closed, whether gate amounts are logged, whether guest identity is logged, whether guest phone numbers are verified, whether guests are sent their pass on WhatsApp, how the venue handles covers, and the venue’s chosen retention window. A venue may also give us a mobile number we can reach it on. It is optional, the owner adds it themselves and confirms it with a one-time code we send to it by SMS, and we use it to recognise a venue that calls or writes to us and to reach that venue about its own account. It is never shown to a guest. A venue’s owner can also give other people at that venue their own sign-in, with narrower rights than the owner’s. The owner gives us the email address; we create the account, generate its password and email that password to the address we were given. What we then hold about that person is the address itself, the venue they were given access to, who granted it and when. The owner can reset that password or remove the access at any time; an account left holding access nowhere can reach nothing at all, and we delete that login rather than keep it. Where a venue turns on the second sign-in step described in section 8, each person who signs in to it may confirm a mobile number of their own, in the same way and with the same kind of one-time code. That number is used for nothing but sending that person their own sign-in code, it is separate from the venue’s contact number above, it is never shown to a guest, and anyone content to take the code by email need not give one at all. We also hold the state of the venue’s own account with us: the plan it is on, the date its trial ends, and the date any hold on its data runs out — section 5.4 explains what those dates do.

We do not collect payment card details, bank details or any financial instrument from a venue. The product itself processes no payments: money at the gate and cover credit are records of what the venue collected, never transactions we handle, and there is no payment gateway anywhere in it. A venue’s subscription is invoiced separately and settled by bank transfer or UPI out of band; what we keep of that is the invoice record — which venues it covers, the amount, and the dates — and never a card number or a bank credential.

2.2Promoter accounts

For a promoter account we collect an email address used for sign-in, a display name, an optional public handle, and an optional contact number. A promoter is added to a venue’s roster only by opening an invitation link issued by that venue; we do not build promoter rosters ourselves.

2.3Guests, through an RSVP

When you RSVP, we collect your name, your mobile number, the size of your group expressed as a count of guys and a count of girls, and your declaration that you are 18 or older. We also record which link you arrived through — a venue can publish its own, or issue one to whoever is running a list for that night — the confirmation code issued to you, the record of your consent, and any marker the venue applies to your entry on its own list. If you came through a list’s link, that link is what tells the venue whose list you are on; if you came through the venue’s own, there is no list and nobody but the venue holds your details.

Your number is also how your entry pass reaches you. If your venue sends passes on WhatsApp — it is a setting each venue controls, and it is on unless the venue turns it off — and your number was confirmed with a code, a message goes to that number carrying your name, your confirmation code and the pass image with its QR. Section 6.2 names WhatsApp’s operator as a processor and says exactly what reaches it.

Your mobile number is the detail that identifies you to that venue. Names repeat too often to identify anyone reliably, so the number, and not your name, is what the venue’s records are organised around. Section 2.6 explains what follows from that.

NightCount never asks anyone their gender, and no record has a field for a person’s gender. What it records is a count of guys and a count of girls for each group: you declare the split of your own group when you RSVP, and at the door it is set from the entry types applied, which staff can adjust where they are correcting what they see. Those counts sit on the group’s own record — your RSVP, or the door entry, which may also carry a payer’s name and number where the venue logs identity — so they are seen by the venue, by whoever runs the list you came through, on your own pass, in the venue’s exports, and in the make-up of your groups the venue sees when it recognises you as a regular (section 2.6). They describe the composition of a group, and are never a gender recorded against each person in it; but for a group of one they are, in effect, a statement of that one person’s sex, and we would rather say so than claim they cannot be read that way.

2.4At the door, and cover credit

When a group is checked in, the venue’s door screen records the number of heads, the entry types applied — which carry the guys/girls make-up of the group, and which staff can adjust — the list or promoter the group is credited to, the time, and the screen that logged it. Where the venue has turned on payment logging, it also records the amount taken at the gate and how it was paid. Where the venue has turned on identity logging, it may record the name and number of one person in the group as the payer.

Money at the gate is recorded as an observation, in the same way a paper register would record it. NightCount does not process, hold, route, refund or take any commission on a payment. Covers are recorded as redeemable food and beverage credit, not as revenue.

Some venues run their covers as credit rather than as a note in a register, and where a venue does, more is recorded about the person who paid. A balance is opened for the group against the payer’s name and number, and every movement on it is kept with its time: the amount loaded at the door, each top-up, each round the bar takes off it, and any reversal. The balance is what the venue owes the group in food and drink, so the record of it is the venue’s own account of the night as well as the guest’s.

A QR code is what opens that balance, and it goes to the payer on WhatsApp with their name, the amount and the venue’s name, alongside a link to a page of their own — described below — which also carries a short code to read out for the times a camera will not scan. Nothing about the balance depends on holding a paper receipt.

What the staff at a bar station see. When a bar screen scans that QR or the code is typed in, the screen shows the name recorded for the payer, the last four digits of their number, the balance left, and the movements on it. Nothing more of you is on that screen, and there is no way to search for you by name or by number: the code is the only key that opens a balance, so a member of staff cannot browse the venue’s guests from a bar screen at all.

Your own page. The link sent with the QR opens your balance on your own phone: the venue and the night, the name recorded for you, what is left, and every movement with its time. Whoever holds the link can see it and can spend against it — that is deliberate, because a group forwards one link between themselves — and the link is replaced if the balance is issued again. Once the night is closed the page shows the venue’s name and nothing else.

Cover credit is for the night it was loaded on. Anything left unspent when the venue closes the night stops being spendable, and is not refunded — that is the venue’s rule, stated on the message you receive and on your own page, not something this policy decides. What that means for your data is smaller: the record of the balance stays as part of the night’s account, and the name and number on it are removed by erasure and by the venue’s retention window exactly like every other record about you (section 5).

2.5Guest records a venue imports from a ticketing platform

A venue may sell tickets for a night through a third-party ticketing platform that is nothing to do with NightCount. Where it does, the venue can upload the list that platform gives it — a file of names and mobile numbers, and optionally a second file marking who actually turned up, which can also add a person that file names and the first did not — so that the night’s records are complete rather than covering only the guests who came through a NightCount link.

If your record reaches a venue this way, the number in it is the number you gave to that ticketing platform when you bought your ticket, not one you gave to NightCount. We did not collect it from you, you did not see this policy at the time, and no consent was taken by us for it. The venue is the party that decides to bring that list across, and it is the venue’s responsibility to have been entitled to do so under whatever terms you agreed with the platform. NightCount processes the file on the venue’s instruction. Your rights under section 9 apply to that record in exactly the same way as to one you created yourself. Erasure under section 5.2 reaches it wherever the file carried your number; a row that arrived with a name and no readable number cannot be found by a number, and is removed when the venue withdraws that import, when its retention window passes, or when its account with us ends.

An imported record is marked as imported for as long as it exists. A mark that you attended, imported from a ticketing platform, is the platform’s claim and is always shown to the venue as a separate, labelled figure — it is never merged into the count of people the venue’s own door actually checked in.

2.6How these become one record about you

A venue can meet you more than once and by more than one route: you might RSVP through a promoter’s link for one night, be logged at the door on another, and buy a ticket through a ticketing platform for a third. Because your mobile number identifies you, the venue sees those as one guest rather than three strangers, and can tell that you have been three times rather than once.

This joining-up happens strictly inside one venue. Your records at one venue are never combined with your records at another, never pooled, and never visible across venues — even when it is unmistakably the same number. That boundary is enforced by the database itself (section 6.1) and is the one rule in this product that does not bend.

What the venue derives from the joined-up record is a count of your visits, when you first and last came, the size and guys/girls make-up of the groups you appeared in, the totals recorded against those groups, and what the door recorded against your own number as the payer. It is used to run and understand that venue’s own nights — above all, to recognise a regular. A venue can set its own rules for that — how many times you came in the last 90 days, the size or the girls’ share of your groups, the cover or table-minimum money recorded against them, alone or combined — and when your record meets one, the venue is shown a suggestion to mark you as a VIP, with the rule it met. A person at the venue accepts or dismisses that suggestion; nothing marks you automatically, and a VIP mark does one thing: it shows on your entry at the door and on your future RSVPs to that venue. It decides nothing else about you, and none of it is shared onwards.

2.7Technical and device data

We keep this deliberately minimal, and we collect none of it for advertising.

• Session cookies. Signed-in venue, promoter and administrator accounts use a session cookie. It is strictly necessary to keep you signed in; it is not used to profile you. Reading our public pages sets no cookie at all: a visitor who has not signed in is given nothing to store, which is why you are not asked to accept anything on the way in. The RSVP page and a guest’s own balance page are public pages in exactly that sense.
• Local browser storage. Your light or dark theme preference is stored in your own browser. On a venue’s door screen, the night’s guest list and the queue of check-ins are stored on that phone so the door keeps working when the network does not. That copy clears itself the next time the screen reaches us and finds its session ended or revoked — which is the honest description of it: a handset that is never switched on again keeps what it last downloaded, and no instruction of ours can reach a phone that never asks for one.
• Anti-abuse records. When a one-time verification code is requested — and equally when an RSVP is accepted without one, at a venue that has verification switched off or during a pause under section 4.2 — we record a one-way hash of the mobile number and the network address the request came from, purely to limit abuse and messaging cost. The code we send is held separately and only as a hash of its own, alongside the same one-way hash of the number, for the few minutes it is valid. The number itself is not stored in either record. When an email address is typed into a signup form we check whether an account already exists for it, so that the form can tell a returning owner to sign in instead — and we record a one-way hash of that address, of the same kind, with the network address the request came from, so that the check cannot be used to walk a company’s staff list. Most of those addresses belong to people who never open an account. The address itself is never stored, and these records are cleared out once they are more than seven days old.
• Administrative audit records. Actions taken by a venue owner, by venue staff or by NightCount staff — a change to venue configuration, an entry voided at the door, a question put to the feature described in section 7 — are recorded with the actor’s identity, the action, the time, and the operational detail of what was done: which setting, which night, which figures an answer drew on. We do not write guest names or numbers into these records, and the wording of a question is not kept in them. Where a venue’s own staff type a note explaining an action, such as why an entry was voided, the note lives on the record it explains, and these audit records keep only the fact that a note was typed, and its length. A note written about a night can be edited by the venue; the reason typed at the door for a voided entry and the reason typed at the bar for a reversed charge cannot be changed once saved, and are cleared when the venue’s account with us ends.

NightCount carries no advertising, no cross-site tracking, and no third-party analytics or advertising software. The application ships with no analytics, advertising or tracking library of any kind. The only picture built about you is the record of your visits to the one venue you visited, described in section 2.6, and it never follows you anywhere else.

2.8If you ask us for a demonstration

Our sales pages carry a form for a venue that wants to see the product. If you fill it in we collect the venue’s name, your name and your email address, and — where you choose to give them — your phone number, your city and whatever you write in the message box. We keep it as the record of your enquiry, so that we can answer it and know that we have. It is never mixed with any venue’s guest records and it is never sent to our artificial-intelligence provider. Nothing removes it on a clock, so it stays until we remove it: write to support@nightcount.com and we will.

Personal data is processed for the following purposes and no others. This is the purpose limitation the DPDP Act requires of us, and it is enforced in the product, not only on this page.

• Running the guest list for a specific night. Your RSVP exists so that the venue — and, where you came through a list’s link, whoever runs that list — knows you are coming, and so that you receive a confirmation code.
• Matching you at the door. Your name and number are how door staff find you on the list when you arrive, whether you show your code or not.
• Getting your pass, and your cover QR, to you. Where your venue sends them, your number is what they are sent to, and your name is on them so you can tell your own pass from a friend’s. These are the only messages NightCount itself sends a guest, apart from a verification code.
• Running cover credit. Where a venue runs covers as credit, the payer’s name and number are what a balance is opened against, so the bar can put a round on the right balance and the guest can see what is left — section 2.4.
• The venue’s own attendance and attribution records. Head-counts, composition and gate totals for the night, and the record of which promoter brought which group, so the venue can credit its promoters correctly.
• Recognising you when you come back. Tying your visits to that venue together, so it knows a regular from a first-timer — see section 2.6.
• Being told about that venue’s upcoming nights. Where you RSVPed and agreed to it, the venue may contact you about nights it has coming up. This purpose is named in the consent notice you saw, not only here — and it belongs to that venue alone.
• Answering the venue’s questions about its own records. A venue can ask questions of its own data in plain English and get an answer back, and where one account operates several venues it can ask how their nights compare. Section 7 sets out exactly what that involves, including what is kept afterwards.
• Keeping the service secure and honest. Rate limiting, abuse prevention, and the audit trail of administrative actions.

NightCount sends you no promotional messages. Not now, and not as a feature we are keeping back — there is no such thing in the product. What we send a guest is a one-time verification code by SMS, and on WhatsApp your own entry pass and, if the venue runs covers, your own cover QR: messages about your own booking and your own money, and nothing else. We send guests no email at all. Where a venue tells you about its upcoming nights, that venue is doing it on its own channels with its own copy of its own guest list. Ask that venue to stop and it stops at the venue; you can also have your record erased under section 5.2.

We do not sell your number, do not share it with other venues, and do not build a profile of you across venues. Your number is used for the purposes listed above, at the one venue that holds it, and nowhere else.

4.1When and how it is taken

Consent is taken from you at the moment you submit an RSVP, on the RSVP screen itself, immediately above the button that confirms it. The notice names all three of the things you are agreeing to, in one line: that the named venue — and whoever runs the list you used, if you came through one — stores your name and number to run that guest list, that your entry pass — and your cover QR, if the venue runs covers — reaches you on WhatsApp, and that the venue may contact you about its upcoming nights. It links to this policy for the detail. Nothing goes on the guest list before you press that button. One thing does happen before it, at a venue that verifies numbers: pressing the button that sends you the code hands your number to our SMS provider to carry it, and writes the anti-abuse record described in section 2.7 — a one-way hash of the number and your network address, never the number itself — which is how a code can be sent, and its abuse limited, at all. The RSVP screen carries links to this policy and to the short guest notice above that button as well as above the one that confirms the RSVP, so the notice is in front of you before either.

Only those three purposes are taken by that consent. If we ever want to take your consent for something the notice did not name, we have to ask you again, under new wording, with a new version. One thing is done under this policy rather than under that consent, and we would rather name it here than let you find it in section 7: when someone at the venue asks a question about their own records in plain English, your name and your mobile number can form part of what is sent to the provider that writes the answer. The notice at the button does not name it. It is disclosed to you here and set out in full in section 7, and whether notice is the right footing for it or whether it must be consented to separately is a question we have put to a lawyer rather than answered ourselves.

Beside that notice is a separate tick confirming that you are 18 or older. It is not a consent to a purpose — it is a statement you make about yourself — and it is required: without it the RSVP is refused, by the database and not only by the screen. What is recorded is that you made the declaration, alongside your consent record.

4.2How the record is kept, and what an older version means

Each consent is recorded with a version identifier, the event it was given for, the time it was given, and whether the 18+ declaration was made, so that we can always show which wording was in force when you agreed to it. That record stores a one-way hash of your number rather than the number itself, so the compliance trail does not become a second copy of your personal data.

The wording has changed three times. It changed most recently on 16 August 2026, when the sentence was recast in plainer language; every purpose it names is unchanged, so nothing anyone had agreed to moved. Before that, on 13 August 2026, it began naming the WhatsApp delivery of your pass and, where your venue runs covers, your cover QR — the same day the 18+ declaration began being collected beside it. That change added a purpose and narrowed none, so nobody who agreed under the previous wording lost anything by it; what they were not told is that a pass would reach them on WhatsApp, and the version on their record is what says so. RSVPs taken before 8 August 2026 carry an earlier version still, and that version named only the running of the guest list — it said nothing about being contacted about upcoming nights. We do not treat those guests as having agreed to something their notice never mentioned, and the version identifier on every record is what makes the groups separable rather than a matter of anyone’s word.

Where a venue has turned phone verification on, we send a one-time code by SMS to confirm that the number belongs to the person making the RSVP. Where a venue has not turned it on, the number is collected but not verified.

There is one more case, and it is ours rather than the venue’s. If code delivery is failing across the platform — our SMS provider is down, or is being abused — we can pause the sending of codes. Where we do that and let RSVPs carry on rather than stopping them outright, a number given during that window is collected but not verified, even at a venue that has verification switched on. Nothing pretends otherwise afterwards: those records carry no verification mark for the rest of their life, exactly like the ones described above, so they can never later be counted as confirmed. The venue is told on its own screen for as long as the pause lasts.

4.3Who may give consent, and withdrawing it

You may only RSVP with your own number, and you may only give consent for yourself. If you enter another person’s number, you confirm that you are entitled to do so on their behalf. If a number has been entered without that person’s agreement, they may have it removed immediately under section 5.

You may withdraw your consent at any time, with the same ease with which it was given, by telling the venue or by writing to us at support@nightcount.com. Withdrawal does not affect the lawfulness of processing before it, and the venue may keep the de-identified head-count and money totals that form its own business records.

NightCount is not directed at anyone under 18, and we do not knowingly process the personal data of anyone under 18. An RSVP cannot be submitted without the declaration described in section 4.1: if you do not confirm that you are 18 or older, no RSVP is recorded. That 18 is the age below which the DPDP Act treats a person as a child; it is used here as a data-protection threshold, not as a drinking age. The legal drinking age is a matter of each state’s own law and is higher than 18 in most states; that declaration is not an age check: it verifies nothing, admits nobody, and authorises no one to serve you alcohol. Venues using NightCount are licensed premises, and checking age at the door, for entry and for service alike, remains theirs to do under the law that applies to them — a tick on a screen is a declaration, not proof, and nothing in this product pretends otherwise.

If you believe a person under 18 has given us their data, write to support@nightcount.com. Only the venue holding the record can erase it, so we pass the request to that venue at once and press it until it tells us the record is gone, and we tell you what it tells us — section 5.2 explains why the removal is theirs to run.

5.1Retention

Retention is controlled by each venue, not by us. Every venue has a retention window, set by default to twelve months and adjustable by the venue between one and one hundred and twenty months. Guest names and numbers are kept for no longer than the retention window of the venue whose night you attended, and may be removed sooner — on the venue’s own initiative or on your request. One exception is deliberate: where the venue has marked you a VIP (section 2.6), your number is kept on that mark for as long as the mark stands, so that your next RSVP can carry it. It goes when you ask for erasure, when the venue un-marks you and the window then passes, and when the venue’s account with us ends.

Two things sit outside the venue’s hands, and we would rather name them than let “controlled by each venue” do more work than it can. The first: our own operator can change a venue’s window, as part of running the platform and setting an account up — every such change is written to the audit trail, and it moves the window rather than reaching into the records. The second: when a venue’s own account with us ends, the clocks in section 5.4 apply as well, and they can be shorter than the window the venue set.

When a retention window is applied, guest and payer names and numbers are cleared from the nights that fall outside it. Where the venue runs cover credit, the name and number on a balance go the same way, and the log of the WhatsApp messages that venue sent over the same period is deleted outright rather than blanked. The de-identified record of the night — head-counts, composition, entry types, gate totals and the movements on a balance — is retained, because it is the venue’s own business record and no longer identifies anyone.

Two stores are ours rather than any venue’s, and each has its own clock. The anti-abuse records described in section 2.7 are deleted 180 days after they are written, everywhere, whatever any venue’s window says. They exist to stop a number or a connection running up messaging cost across the whole service, and that job is done long before then. The signup-check records described in the same section are cleared out once they are more than seven days old, which is longer than any window the check itself looks back over.

The window reaches the stored questions and answers described in section 7.3 as well, and it is the only clock on them. A chat is deleted in full once it was started longer ago than the venue’s window allows — the question, the answer, and the table of results frozen alongside it. Because that clock runs from the day the chat was started and not from the night it discusses, a chat about an older night can keep a name or a number for up to one window after the night’s own record has been cleared; an erasure request under section 5.2 reaches it at any time.

5.2Erasure

You may ask for your personal data to be erased at any time. The quickest route is to ask the venue directly, because the venue holds the record and can act on it immediately. You may also write to us at support@nightcount.com, telling us the venue and approximately when you attended, and we will pass the request to that venue and chase it until it is done. We should be straight about the limit of that. Only the venue’s own owner can run an erasure — a manager cannot, the database refuses it — and the permissions described in section 6.4 mean we can neither run one on the venue’s behalf nor read the record to check it afterwards. What we can do is relay your request, chase it, and tell you what the venue tells us.

Erasure removes your name and mobile number from that venue’s records across every one of its events, and deletes the request records described in section 2.7 — the rows that count how often a code was asked for against your number. The one-time codes themselves sit in a separate store your request does not reach: they are dead within minutes of being sent, and they are deleted on the 180-day clock in section 5.1, or sooner if that venue’s own account with us ends (section 5.4). Erasure reaches the cover rail too: the name and number come off any balance opened for you, and the log of WhatsApp messages that venue sent you is deleted. What remains is the de-identified count of the night and the money movements on that balance, which no longer identify you.

Because your number is the thing that identifies you (section 2.6), a single erasure request covers every record keyed to that number at that venue — the RSVPs you made, the door records naming you as the person who paid, any balance opened for you, and the rows imported from a ticketing platform alike. You do not have to know which of them exist, or ask separately for the ones that arrived by a route you never used.

The same is true of the retention window in section 5.1: when it is applied, imported records fall out of it exactly as RSVP and door records do.

One limit on that is worth stating plainly rather than leaving you to discover it. Where a member of the venue’s own staff has typed your name or your number into a note in their own words — the reason an entry was voided at the door, the reason a charge was reversed at the bar, a note written about the night — that note is free text the venue composed, and an erasure keyed to your number does not search it. It is the venue’s record and the venue can change it, so ask them; the section 5.1 retention window does not reach those notes either, and they are cleared when the venue’s own account with us ends, under section 5.4. The stored questions and answers in section 7.3 are the exception to that shape — they are free text as well, and they are searched for your number, as the next paragraph describes.

Erasure also reaches the stored questions and answers described in section 7.3. Where your number appears in one of them — in the question someone typed, in the answer written back, or in a table of results frozen alongside it — that exchange is deleted: the question and its answer together, and the frozen table with them. Your number is taken out of the chat’s own title if it was there, and if nothing is left of the conversation afterwards the conversation goes too. Otherwise the rest of it stays, and the person who asked is shown a note on it saying that something was removed to honour a deletion request, so their history is not quietly rewritten. A stored answer is not a place your details get to outlive a request to erase them. A conversation that mentions you only by name, and never by number, is not searchable for you without reading other guests’ conversations too; those are deleted by the venue’s retention window instead, described in section 5.1.

One record is deliberately preserved: the consent record described in section 4.2, which holds a one-way hash of your number, the event and the version of the wording you agreed to. It contains neither your name nor your number. We retain it as the accountability record a data fiduciary must be able to produce.

5.3When a venue stops using NightCount

A venue’s account can be in one of three states, and which one it is in changes what happens to the records it holds about you.

• Suspended. The venue can still sign in, read its own history, export its own data and act on erasure and retention requests, but it cannot run a night: no new event, no new RSVP, no door screen, no reporting email. This state is deliberately not a lockout. The venue is the data fiduciary for its guest records, and shutting it out of its own erasure and export paths would stop it answering you.
• Deactivated. The account is closed. Nobody at the venue can sign in or reach any screen, and no guest link for that venue resolves. The records still exist, because deactivation can be reversed — an account closed by mistake, or in a dispute, is not a reason to destroy a guest list. One consequence you should know about: while an account is in this state, nobody can act on an erasure request for it. The venue cannot reach its own controls, and NightCount holds no erasure power of its own — section 5.2 explains why. If you write to us about a venue in this state we will tell you so, and we will ask its owner to bring the account back for long enough to answer you.
• Purged. Permanent. Reachable only from deactivated, and only after the operator types the venue’s name to confirm. Everything that identifies a guest at that venue is destroyed: the guest list itself, the names and numbers on it, the payer name and number recorded at the door, the notes staff typed about a night, a voided entry or a reversed charge, the regulars flagged for the venue, every stored question and answer described in section 7.3, and everything imported from a ticketing platform. The pairings that connect the venue’s door and bar screens go with it, and the copy each screen holds clears itself the next time that phone reaches us, as section 2.7 describes. There is no recovery step inside the Service and we never put the records back. One honest qualification, the same one the Terms of Service carry: we take operational backups of the whole database so the Service can be recovered from a failure, and a backup taken before a purge still contains what was purged until that backup is itself deleted. Each backup is encrypted when it is written and is deleted thirty days after it is taken, so that window is bounded rather than open-ended. Backups are restored only to recover the Service after a failure or an operator mistake. A restore puts the whole database back to the moment the backup was taken, which can bring back records destroyed or erased after that moment; we do not restore a backup to serve, share or reinstate one account’s data on request.

Four things survive a purge. The first is the de-identified record of the nights themselves — head-counts, composition, entry types and gate totals, which name nobody. The second is the consent records described in section 4.2. Those hold a one-way hash of a number and never the number itself. They are stable pseudonyms rather than anonymous data, and we would rather be exact than flattering: the hash is made the same way every time, with a secret key our application holds and the database never does, so a copy of the database on its own cannot be turned back into a number. We hold that key, and Indian mobile numbers are a small enough range that someone holding both it and these records could work back from a hash by testing candidates. Nothing in the Service does that, and no consent record is ever used to contact anyone. What they still prove is that a consent was recorded, on a date, under a stated version of the wording. That is the venue’s only remaining answer if it is later asked to account for having held your data, which is why it is kept when everything else is not.

The third is the anti-abuse records described in section 2.7 — the one-way hash of a mobile number and the network address a verification code was requested from, and the short-lived record of the code itself. Those are not the venue’s to destroy: they are held by NightCount across the whole service, not by any one venue, and they are what stops the same number or the same connection being used to run up messaging cost at every venue at once. A purge is scoped to one venue and cannot reach them without disarming that protection for every other venue too, so it leaves them alone. They do not last indefinitely for that reason: they run out on their own 180-day clock, described in section 5.1. Like the consent records they carry a hash and never the number, and they carry the same qualification: nothing in the Service turns one back into a number we are not given, and the secret that makes them is held by our application rather than by the database.

The fourth is the venue’s own audit trail, described in section 2.7 — the record of who did what in that venue’s console, and when. It is kept so that what was done can still be accounted for after the records it was done to are gone, and a purge does not reach it. What we write into it is metadata: the actor, the action, the time, and operational figures — we do not write a guest’s name or number into it, and we do not write prose. Where a member of the venue’s staff typed a note to explain a voided entry, the trail records only that a note was typed and how long it was; the note itself lives on the record it explains, and the purge destroys it with everything else. Nothing prunes this trail, so anything that reaches it stays.

A purge is limited to the one venue. Where the same person operates more than one venue, purging one leaves the others exactly as they were. Every one of these three actions is recorded in the administrative audit trail, and that record is written so that it outlives the data it describes.

5.4When a venue’s account with us ends

The states in section 5.3 are what an operator does. Two clocks run on their own, and because they can be shorter than a venue’s retention window they are set out here in full.

• A trial that is not taken up. A venue that signs up gets 7 days. When that trial ends the account becomes read-only: the owner can still sign in, read the venue’s reports and guest list, export it, erase a guest and run retention, and anyone the owner has given limited access can still sign in and read what that access reaches, but the venue cannot run another night — no new event, no new RSVP, no door or bar screen, no cover credit. Sixty days after the trial ends, everything that identifies a guest at that venue is destroyed, in the way section 5.3 describes for a purge. Taking up a paid plan stops both clocks — including after the trial has run out, at any point before those sixty days are up.
• An account that leaves. When a venue stops using NightCount — it cancels, or it is taken off a plan — we take it off its plan, which puts the account into that same read-only state and starts a 90-day clock. Its owner keeps those 90 days to read and export what the account holds, anyone given limited access keeps the same days to read it, and at the end of them the same destruction runs on its own. A cancellation is carried out that way too: it is the same step, taken by us on the day you tell us.

Both clocks are worked once a day rather than to the minute, so read “when the trial ends” and “sixty days after” as the day rather than the hour. Neither is a floor: throughout the window the venue can still erase a guest, and still shorten its retention window and apply it, so records can go sooner. You can ask for erasure under section 5.2 the whole way through — the read-only state is deliberately built so that a venue on its way out can still answer you.

What that destruction leaves behind is what section 5.3 leaves behind: the de-identified record of the nights, which names nobody, the consent records, which hold a one-way hash and never a number, and the venue’s own audit trail, metadata only, as section 5.3 describes. It reaches one thing a purge does not — the anti-abuse records for the numbers that venue’s own consent records can vouch for are deleted with it, ahead of their own clock.

The consent records are kept through all of this, deliberately. They are the accountability trail a data fiduciary must be able to produce, and they carry a hash and never your number. The secret the hash is computed with is held by our application and never by the database, so a copy of the database on its own cannot be turned back into a number. We hold that secret, and Indian mobile numbers are a small enough range that we could work back from a hash if we set out to. Nothing in the product does, and no consent record is ever used to contact anyone. Whether the right to erasure should override that duty is an open question we have put to a lawyer rather than answered ourselves, and this page will say so until it is settled.

6.1Separation between venues and promoters

Venue data and promoter data are kept in separate silos, and the separation is enforced by the database itself rather than by application convention.

• A promoter can see only the guests on their own list, for any night they have worked. That view is theirs and stays theirs: revoking their link stops new work, but it does not remove their view of the guests their link already brought, and it travels with them across the venues they work. A guest’s erasure and the venue’s retention clean-out still reach those records, because they are the same records. A promoter can never see another promoter’s guests.
• A promoter can never see the money taken at the gate.
• A venue can see only its own venue’s records. Guest data is never pooled across venues, and one venue’s guest list is never visible to another. Where one account operates several venues, that account can compare their night totals — but each venue’s guests stay that venue’s own, and no guest record crosses between them.

These boundaries are implemented as row-level security rules in the database, enforced on every read and write, and each is asserted by an automated test suite kept in the same repository as the code, so a change that weakened one would fail before it could ship.

6.2Our processors

Seven service providers process personal data for us, each on its published terms for business customers. This is the whole list — Supabase, Vercel, Resend, 2Factor.in, Meta Platforms, Google and Anthropic — and if it ever gains an eighth, this page changes before that provider is switched on. Those terms confine what we send a provider to delivering its service to us: we give none of them data to sell, to advertise with, or to build anything of its own from. Where a provider also handles technical or account data to run and secure its own platform, it does so under its own terms rather than on our instruction.

• Supabase — database, authentication and file storage. NightCount’s data is hosted in the Mumbai region (ap-south-1). The permissions described in section 6.4 bind the accounts and keys the application runs with — the console our staff use and the keys our servers hold. They do not bind the company that runs the database, and they do not bind the database-administrator credentials we ourselves keep for backups and maintenance. Supabase administers the servers and the disks your data sits on, and its own infrastructure staff can in principle reach what is stored there, as is true of any hosted database anywhere. That is one of two routes those permissions do not close; ours is the other, and section 6.4 sets it out. We would rather say so than let “cannot read” be heard as a claim about everyone.
• Vercel — hosting and delivery of the web application.
• Resend — delivery of the email we send: sign-in links, invitations and address confirmations for venue and promoter accounts; the password we generate when a venue’s owner gives someone limited access, and the one-time sign-in code where a venue has turned on the second step described in section 8; notices about a venue’s account; and the night report and weekly summary a venue’s owner has chosen to receive, which carry that venue’s figures and its promoters’ names, and never a guest’s name or number. Two of the messages it carries come to our own mailbox rather than to you: the enquiry you send us through the form on our sales pages, described in section 2.8, and the alert that tells us a venue has opened an account, which carries that venue’s name and city and the address it signed up with. Guests receive no email from us.
• Google — the mailboxes that receive what you send us. The address printed throughout this policy, including the grievance address in section 9, is a Google Workspace mailbox, so an email you write to us and our reply to it sit with Google under its own terms. Nothing about a venue’s guest records is put there by the product; what is there is what you chose to write to us.
• 2Factor.in — delivery of the one-time code by SMS, at venues where phone verification is turned on. They receive your mobile number and the code, for that delivery alone, and the message is sent over Indian mobile networks. Where a venue has phone verification turned off no guest code is sent, and a guest’s number never reaches this provider — but a venue that asks us to confirm its own contact number, under section 2.1, sends that number to this provider for the same one delivery. The same is true of the number a person at a venue confirms for their own sign-in code, and of every sign-in code afterwards sent to it, where that venue has turned the second step on.
• Meta Platforms (the WhatsApp Business Platform) — delivery of the two messages described in section 2.3 and section 2.4: your entry pass, and your cover QR where the venue runs covers. Meta receives your mobile number and the contents of the message, which are your name, your confirmation code or the amount and the venue’s name, and a link to the pass or QR image, which Meta fetches from us as it sends. Delivery reports come back to us keyed by the identifier Meta gives the message: our record of a send stores that identifier and a one-way hash of your number, never the number itself. Anything you reply to one of those messages is discarded unread by that system.
• Anthropic — the artificial-intelligence provider whose model answers a venue’s questions about its own records. Guest names and mobile numbers can form part of what is sent. Section 7 sets out when this happens and what the limits are.

Where they are. The database that holds a venue’s records is in India, in the Mumbai region, and so is the application that answers your requests: it runs in our hosting provider’s Mumbai region. Verification codes go out over Indian mobile networks. The rest — the hosting provider’s own build, logging and content-delivery systems, account email, our own mailboxes, WhatsApp delivery and the artificial-intelligence provider — process outside India, so your data is transferred outside India for those purposes and for no other. We do this on the terms each of them offers a business customer, and section 8 describes the safeguards that travel with it.

We do not sell personal data, and we never will. We do not share it with advertisers, data brokers or any other third party for their own purposes. We disclose personal data to a public authority only where we are required to by law.

6.3What the venue takes out, and what it does with it

A venue’s owner can export that venue’s own guest records as a file. That is the venue’s data, held on its instruction, and the export is how the venue keeps its own copy — to work offline, to move to another system, or to contact its guests about upcoming nights on its own channels.

Once a venue has exported that file, what happens to it is the venue’s responsibility as data fiduciary, on its own systems and its own messaging accounts. NightCount is not in that loop: we do not send those messages, we do not see them, and we cannot stop them. If you want a venue to stop contacting you, tell that venue — and you can have your record erased under section 5.2, which removes what it would export next time.

The export is restricted to the venue’s owner, and only where that venue has turned identity logging on. Managers and door staff cannot take guest identity out of the product, and promoters can never export anything beyond their own list.

6.4What NightCount’s own staff can see

The account NightCount’s staff work from, and the application key our servers run on, hold no privilege on any table that stores a guest’s name or number in a field meant for one. The database refuses them — that is a permission, not an internal rule we promise to follow. Reaching those details at all takes the credentials that administer the database, which exist for backups and recovery. We are prohibited from using them to read a guest list, and the paragraphs below say exactly what that leaves.

We operate the platform: we onboard a venue, keep the service running, and look into a fault when one is reported. None of that requires seeing who is on a guest list, so the account we do it from has been denied that data outright. The database returns nothing to it from every table that holds a guest’s name or number, the record of a night among them. The application key our servers run on — the one that normally bypasses those checks — was stripped on 8 August 2026 of every privilege on the tables that keep those details in a field of their own, and holds none. Every table built since, the cover-credit records among them, has been created that way from the start. A test in this repository asserts each of those permissions and fails if a later change re-opens any of them, so it cannot be quietly undone.

One table sits outside that second permission, and we would rather name it than let the sentence above be read wider than it is. The record of a night itself — the venue’s head-count figures, its own bar total, and the note its staff type about that night — has no field for a guest’s name or number, and nothing on it is organised around you. But a member of the venue’s staff who writes a name into that note has put one there, and the application key can still read that table. The account our staff work from cannot: the database returns it no row of that table either, and the same test asserts it. The note itself is the venue’s to change, and it is cleared when the venue’s own account with us ends, as section 5.2 explains.

We are telling you the limit of that as well. The parts of the service that must handle your name to do their job still do — the RSVP page writes the name you type, and the door screen downloads the night’s list so staff can find you at the door. Those run for the venue, on the venue’s instruction. If a venue asks us to look at one specific guest record we say no, and the venue does it in its own console.

Two routes to that data nonetheless exist, and we would rather name them than have you find them. The first is the credentials that administer the database. We hold them, and use them to apply changes to the database’s structure and to take the backups described in section 5.3 — and a backup is a complete copy, guest names and numbers included. Each backup is encrypted as it is written, is recorded with the reason it was taken, and is deleted after thirty days. This access is not restricted by the permissions described above, which is precisely why it is written here rather than left implied. The second is resetting a venue owner’s login: where a venue has lost access to its own account, we can issue that owner a password-reset link, and whoever holds that link can enter the venue’s console and see its guest list. That action requires a second authentication factor, is written to an append-only record before the link exists, and resets the owner’s password — so the venue is locked out of its own account and learns that it happened. We are prohibited from using either route to read a guest list, except where you instruct us to, where it is necessary to restore the Service after a failure, or where the law compels us. No system can be guaranteed secure, and we do not claim otherwise.

One narrow diagnosis is worth stating plainly. If a venue reports that a guest never received their verification code, the venue can read us that number and we can check whether a code was sent to it, when, and whether it was confirmed. The number is turned into a one-way hash the moment it reaches us and is matched against the anti-abuse records described in section 2.7; it is not stored, and no digit of it is ever displayed back. We can confirm the status of a number a venue already has. We cannot discover one, and we cannot list them.

6.5If you message us yourself

Our own pages carry a button that opens a WhatsApp chat with our business number, and our email address is on them. If you use either, we hold what you send us and our reply, for as long as we need it to answer you and to keep a record of having answered. A WhatsApp conversation with us also sits inside WhatsApp, on your phone and on theirs, under WhatsApp’s own terms and privacy policy rather than this one — that is a service you already use, and we are just another contact in it. The number that button opens is answered by a person, and is not the number the messages in section 6.2 are sent from.

A venue can ask questions about its own records in plain English — how a night went, who its regulars are, which promoter brought whom — and get an answer written back in sentences. Where one account operates several venues, it can also ask how those venues compare to each other. To do that, the relevant records are sent to our artificial-intelligence provider, Anthropic, which returns the wording. This section is the honest account of what that involves, because it is the one place where data about you leaves our own systems for something other than delivering a message to you.

7.1What can be sent

What is sent is drawn from the asking venue’s own records and can include guest names and mobile numbers, along with visit counts, group sizes, entry types, gate totals, promoter names and the venue’s own performance figures.

Two kinds of question reach that far, and it is worth being exact about them. A question about the venue’s guests can send, for each guest it answers with, their name, their mobile number in full, how many times they have been and how many of those visits were in the last ninety days, when they first and last came, how many heads their groups bring on average and the guys and girls in those groups, whether the venue has marked them a VIP, and whether their consent allows the venue to contact them about upcoming nights. Where the venue logs what is taken at the gate, or has logged it in the past, it can also send the total recorded against the groups they appeared in with its per-night and per-head averages, how many nights of theirs have money logged against them, how many of their groups were on a table minimum, and — where the door recorded that guest’s own number as the payer — what they paid at the gate and its per-night average. A question about cover credit can send, for each person who paid, their name, their number in full, and what they loaded, spent and left unspent when the night closed. Every other question is answered from figures and from promoter names, and no guest is named in any of them.

Where one account operates several venues and the question compares them, the other venues’ night totals are sent as well — head-counts, group counts, RSVP counts, conversion and gate figures for a night. Nothing about the guests of those other venues is sent: the feature has no way to read them at all.

This is a change. Until 8 August 2026 guest mobile numbers were stripped before anything reached the provider. They are not stripped any more — a venue asking about its guests may have their numbers included in what is sent. We would rather say that plainly here than leave an old promise standing on this page.

Anthropic processes what is sent outside India, which is why it is named in the transfer paragraph in section 6.2 as well as here.

There is one other, much smaller place the same provider is used. When a venue uploads a guest list from a ticketing platform, the model is asked which column is the name, which is the phone and which is the party size — and to do that it is sent the column headings, and then only ones spelled the ordinary way, along with the shape of a few cells and never the cells themselves: a name travels as “Aa Aa” and a number as a run of digit marks. No guest’s name or number is in what is sent, the answer is only a suggestion, and the venue confirms the mapping itself before anything is imported.

7.2The limits that still hold

• Only that account’s own venues. A question is answered against the records of the venue asking it, read with that person’s own permissions. Where the same account operates more than one venue, a question that compares them also reads those other venues’ night totals, and nothing else about them. No guest of another venue is ever read, and a venue the asking account does not operate cannot be reached at all — the same database boundary described in section 6.1 applies to every read the feature makes.
• Reading only. The feature can read and describe. It cannot change a record, delete one, send a message, or move data anywhere. There is no route by which an answer becomes an action.
• Asked, not always on. Anything about you is sent only when someone at the venue asks a question. Nothing about you is sent on a schedule, and nothing is sent about the guests of a venue that never asks. There is one scheduled use of the same provider — the weekly summary a venue’s owner receives — and it is written from that venue’s totals for the week alone: head-counts, composition and gate figures, with no guest name or number in it, and with each promoter it mentions reduced to a label with no name attached before it is sent.
• Not used to build anything. What is sent goes in order to answer the question it was sent for. We do not train anything on your data, we have nothing to train, and no model of any kind is built from a venue’s records or from what you did at a night. What the provider may do with what it receives is governed by the commercial terms we hold with them, not by a promise we can make on this page — and we would rather tell you where the line is than describe someone else’s obligations as if they were ours.
• No decisions about you. Nothing here decides anything about you. It does not set prices, does not rank guests for admission, and produces no output that gates your entry — whether you get in is a decision made by people at a door.
• Logged. Every question that is answered is recorded in that venue’s own audit trail: who asked, when, and which figures the answer drew on. A question refused before anything is read — because the venue’s allowance is used up, or because the feature is paused — leaves no row, and neither does a question cut off because the asker’s access was removed while it ran. The wording itself is not kept there — it is kept in the chat, which section 7.3 explains.

Account email addresses — those of venue, promoter and administrator accounts — are not part of what is sent.

7.3What is kept afterwards

A question and its answer are not thrown away once read. Each exchange is stored as a chat, so the person who asked can return to it, and so that re-opening an old answer shows the figures as they stood on the day rather than quietly recalculating them. That store holds the wording of the question, the wording of the answer, and the table of results shown alongside it. Because a question can be about guests, a guest’s name or mobile number can be sitting in any of the three.

A chat is visible only to the person who asked it, and only within the venue they asked it about — not to their colleagues, and not to any other venue. They can delete it at any time. Left alone, it is deleted when the venue’s own retention window in section 5.1 runs out, counted from the day the chat was started. There is no separate clock for chats and no arrangement under which a chat that stays in use survives the window. Because that clock is counted from the start, a chat opened late in a window about an earlier night can hold a name or a number for up to one window after the night’s own record was cleared — section 5.1 says so, and it is the one way this store can outlast the records a name came from. An erasure request under section 5.2 reaches it sooner: a name or number that erasure removes from the venue’s records is removed from these stored chats too, and the person who asked is shown that something was removed.

We take the reasonable security safeguards the DPDP Act requires. Specifically:

• Personal data is encrypted in transit and encrypted at rest by our hosting processors.
• Access is isolated at the row level in the database. Every read and every write is authorised against the identity of the caller, and the default is to deny.
• Accounts and screens hold the least privilege they need. Door staff have no personal accounts: a door screen is paired to the venue with a PIN and holds a scoped session that expires and can be revoked at any time.
• Mobile numbers held for rate-limiting and consent records are stored only as a one-way hash, taken with a secret key the application holds and the database never sees, so a copy of the database on its own reveals no phone numbers. The same number always produces the same hash — that is what lets us apply a rate limit and act on an erasure request — so these are stable pseudonyms rather than anonymous data. Sections 5.3 and 5.4 say what that means where they are all that is left.
• One-time verification codes are stored only as hashes, expire after a short period, and are limited by attempt.
• A venue can require a second step when its people sign in. Where it is on, a password on its own reaches nothing: the account must also enter a one-time code we send to its own email address, or by SMS to a mobile number that account confirmed itself, and until it does the database refuses that session the venue’s guest and night records. That verification lasts twelve hours and is then asked for again. It is off unless the venue’s owner turns it on.
• Administrative actions are written to a tamper-evident, append-only audit log.
• The permissions that deny guest names and numbers to NightCount’s own staff, described in section 6.4, are part of this security model rather than a policy sitting on top of it, and are re-proved automatically on every change to the system.

No system is perfectly secure. In the event of a personal data breach we will notify the Data Protection Board of India and every affected data principal, in the manner and within the time the DPDP Act requires.

As a data principal under the DPDP Act you have the right to:

• Access — obtain a summary of the personal data being processed about you and the processing activities undertaken.
• Correction and completion — have inaccurate or misleading data corrected, incomplete data completed, and data updated.
• Erasure — have your personal data erased, subject to the retention we are required by law to maintain. See section 5.2.
• Grievance redressal — a readily available means of raising a complaint about how your data has been handled.
• Nomination — nominate another individual to exercise these rights on your behalf in the event of your death or incapacity.

How to exercise them. If you are a guest, the fastest route is the venue you attended, which holds the record and can act on it directly. You may also write to us and we will act on, or pass on, your request. If you hold a venue or promoter account, the data and privacy controls are in your account settings, and you may write to us as well.

One of those rights works differently, and you should know how before you rely on it. Nothing in the product edits a guest record. Neither the venue nor NightCount can change a name, a number or a group’s composition on a night that has already happened. What corrects a detail is your next RSVP: RSVP again to the same night with the same number and the name and group size on that record are replaced with what you type. For a night that is over, the remedy the product actually has is erasure under section 5.2, and we would rather tell you that than list a right we cannot deliver.

Contact and grievances. The grievance officer is Rishiraj Guha Ray, the proprietor named in section 1. Write to support@nightcount.com. We acknowledge a request within 72 hours of receiving it, and answer it within the time the DPDP Act and the rules made under it require. We may need to ask you for information sufficient to confirm that the request is yours — typically the venue and the night in question — before we act on it. If you are not satisfied with our response, you may complain to the Data Protection Board of India.

We may update this policy as the service changes or as the law requires. Any material change will be posted on this page with a new effective date, and venues using NightCount will be notified where the change materially affects how guest data is handled. The version in force is always the one published here.

This policy is effective from 19 August 2026. It replaces the version of 17 August 2026, and the changes are these: what the guys and girls counts are, where they sit, and everywhere they are seen is stated in full, and the claim that they could never be attached to an individual is withdrawn (sections 2.3 and 2.4); the entry pass reaches you on WhatsApp only where your number was confirmed with a code (section 2.3); erasure is stated to reach an imported record wherever the file carried your number, and the three other ways such a record goes are named (section 2.5); the rules a venue can set to be shown a suggestion to mark you a VIP, and what that mark does, are described, and the sentence saying your record is not used to score you is withdrawn (section 2.6); what happens when you press the button that sends you a code — before any RSVP exists — is stated, and the RSVP screen now carries this policy and the short guest notice above that button too (section 4.1); the one exception to the retention ceiling, a standing VIP mark that keeps your number, is named (section 5.1); the chat store is stated to run on a clock counted from the day a chat began, so a chat about an older night can hold a name for up to one window longer than the night’s own record, and the two sentences that denied it are withdrawn (sections 5.1 and 7.3); the application that answers your requests is stated to run in India, and the hosting provider’s transfer is scoped to its build, logging and delivery systems (section 6.2); the list of what a question about guests can send is brought up to date, and now includes the VIP mark, the consent answer, the guys and girls in a guest’s groups, and what the door recorded that guest paid (section 7.1); and the three cases in which a question leaves no row in the venue’s audit trail are named (section 7.2). The version of 17 August 2026 had replaced the version of 16 August 2026, and those changes were these: the record we keep when an email address is typed into a signup form is described, with the clock on it (sections 2.7 and 5.1); the optional mobile number a venue may give us, and the one-time code that confirms it, are named where what we collect from a venue is listed (section 2.1) and where our SMS provider is described (section 6.2); the enquiry you send us through the form on our sales pages, and the alert that tells us a venue has opened an account, are named among the email that goes through our delivery provider (section 6.2); and the permission that keeps our staff account and our servers’ own key away from guest details is stated with the one table it does not reach, which is the record of a night and the note a venue’s staff type on it (section 6.4). The version of 16 August 2026 had replaced the version of 14 August 2026, whose one change was this: the consent history in section 4.2 now records a third revision of the RSVP sentence — a plain-language recast on 16 August 2026 that added no purpose and narrowed none. The 14 August 2026 version had replaced the version of 13 August 2026, and the changes were these: Google is named as a seventh processor, because the mailbox this policy tells you to write to is a Google Workspace mailbox (section 6.2); what our database host can in principle reach is stated beside the permissions that cannot bind it (section 6.2); the record of a demonstration enquiry is described (section 2.8); the venue’s own audit trail is named as a fourth thing that survives a purge, and the little it holds is spelled out (sections 5.3 and 5.4); the hashes in the consent records are described exactly — they can confirm a number they are given and can never produce one (sections 5.3, 5.4 and 8); the limits of erasure by request, of correction, and of a deactivated account are stated rather than implied (sections 5.2, 5.3 and 9); the collection notice covers a venue’s own link as well as a list’s (section 2.3); and what is done under this policy rather than under your RSVP consent is named where consent is described (section 4.1). The version of 13 August 2026 had in turn replaced that of 8 August 2026: it named WhatsApp as the way a guest’s pass and cover QR reach them and Meta Platforms as a processor, described the cover-credit records and the 18+ declaration, set out the two clocks that apply when a venue’s own account with us ends, stated what a question about guests or about cover credit sends to our artificial-intelligence provider, and put the operating entity, the grievance officer and the governing law on the page. Questions about any of it should go to support@nightcount.com.

You can return to the NightCount home page at any time.