Legal Change Log

A dated, plain-English record of every change to a published bartendersNow™ legal document.

How to read this log. Each entry names the documents affected, classifies the change, states what the document said before and what it says now, why it changed, and the effect on you. We say "the Terms said X from [date]" — never "the Terms always said X." A corrected term applies from the date of its entry below, not retroactively.

Classification. A minor correction moves no operative term — no fee, payout, cancellation, refund, dispute-resolution, or data-practice term changes — is not adverse to any user, and conforms a document to practice already in place. It is published with an entry here; the Terms of Service version is unchanged and no re-acceptance is required. A material change does the opposite: it bumps the Terms of Service version, sends email notice, and requires re-acceptance in the app before you continue.

Questions about any entry, or a request for the superseded text: legal@bartendersnow.com.

---

2026-09-19 — We describe what happens when someone without an account asks us to email a Stock List

Documents affected: Privacy Policy — §2.4 (Information from Non-Users), §3.4 (Communications), §5.1 (Retention Periods), §8.4 (Email Tracking Technologies), §12.2, §12.3 and §12.4. Last Updated September 15, 2026 → September 19, 2026. The Effective Date does not move.

Classification: a new disclosure, published before the collection begins. Our free Stock List tool on the marketing website is getting a "Send me a copy" option: you can ask us to email you the list you just generated, and you can separately choose to subscribe to our news and updates. Neither exists for the public yet — this entry is the notice that it is about to, and the option does not go live until this text is published. It moves no fee, payout, cancellation, refund, or dispute-resolution term, it changes nothing about any account or any message a Host or Bartender receives, the Terms of Service version is unchanged, and no re-acceptance is required.

What the documents said before this date. The Privacy Policy described one kind of collection from people without an account besides legal and abuse reports: launch-notification requests. It said nothing about emailing a copy of a planning-tool result to someone who asks for one.

What they say from this date. If you do not have an account and you ask us to email you a copy of a Stock List, we collect your email address and your confirmation that you are 21 or older, we use the event details you entered to produce the copy, and we do not keep those details with your address. If you do not subscribe, we do not keep your address at all. Subscribing is a separate, optional choice that is never pre-selected, you get your copy whether or not you make it, and we do not add you to the list until you confirm by clicking a link in a message we send you. We do not sell or share any of it. Section 5.1 now carries the retention periods, including that we delete an unconfirmed subscription request once it is more than thirty (30) days old. We also corrected one sentence about launch-notification requests, which listed the email address and area but not the age confirmation we have collected with them since September 8, 2026. We also state in Section 8.4 that the copy we email when you ask us for a Stock List, and the message we send to confirm a subscription, carry the same delivery, open, and click measurement as the other email we send, which we use only to confirm that the message you asked for was delivered and worked.

Effect on Hosts, Bartenders, and visitors. None to anything about a booking, a payout, a cancellation, or a fee, and none to any message sent to an account holder. For a visitor who uses the option once it is live, the effect is the one described above.

Prior text. The superseded Section 12.2 sentence is quoted in substance above. The full superseded text of each affected section is retained in the version record and is available on request at legal@bartendersnow.com.

2026-09-19 — Our cookie inventory now covers the marketing website's attribution key, and the Privacy Policy names the campaign parameters

Documents affected: Cookie Policy — §11.5 (heading, introduction, and the bhm-marketing-attribution-v1 row). Last Updated September 12, 2026 → September 19, 2026. Privacy Policy — §2.2 (Information Collected Automatically). Last Updated September 15, 2026 → September 19, 2026. The Effective Date of each document does not move.

Classification: a minor correction plus one new disclosure, and no fresh cookie-consent request. The Cookie Policy change is a scoping correction: Section 11.5 described only our web application, and the storage key it lists is now written by our marketing website as well. The Privacy Policy sentence is a new disclosure of something the Cookie Policy already described, closing a gap between the two documents. No cookie category changes, no new purpose, no new provider, and no new category of personal information, so we are not asking you for your cookie choices again. The Terms of Service version is unchanged and no re-acceptance is required.

What these documents said before this date, in their own words. The Cookie Policy's Section 11.5 was headed "App Storage — Similar Technologies" and its introduction read "The bartendersNow™ web application uses a small number of first-party browser-storage keys (local and session storage) rather than cookies for these functions." The bhm-marketing-attribution-v1 row gave its purpose as "Captures marketing-attribution parameters (e.g., UTM tags) from the link that referred you, for first-party attribution," and its Type read "Functional / analytics (first-party)." The Privacy Policy said nothing about campaign parameters at all: Section 2.2 listed platform usage, location, performance, and analytics data, and no campaign, referral, or attribution information.

What they say from this date. Section 11.5 is headed "App and Marketing-Site Storage — Similar Technologies" and its introduction covers the web application and the marketing website. The bhm-marketing-attribution-v1 row now names the three parameters it holds — utm_source, utm_medium, and utm_campaign — says that we pass them to our app when you continue there, states that it contains no name, email address or account identifier, and names both surfaces. Its Type now reads "Essential / functional (first-party)." The Privacy Policy's Section 2.2 now lists those same campaign parameters under a "Marketing Attribution" heading and states that they contain no information about you.

Why it changed. Our marketing website now keeps the campaign parameters carried by the link you arrived on, for the length of your browser session, and passes them to our app if you continue there, so that we can understand which channels bring people to bartendersNow™. The section that inventories that storage key described only the app, and the key's stated type did not match how we treat it. Both are corrected here, and the Privacy Policy is brought into line with what the Cookie Policy already disclosed.

Effect on Hosts, Bartenders, and visitors. None to anything about a booking, a payout, a cancellation, or a fee, and none to any message you receive. The key is cleared when your browser session ends. Your cookie choices are unchanged, and you will not be asked for them again because of this entry. The re-prompt described in Section 11.4 is triggered when the choices themselves change — a new or re-scoped category, a new purpose, a new provider, or a new category of personal information — and not by every update to this document's date; none of those changed here.

Prior text. The superseded Section 11.5 heading, introduction, and row are quoted above. The full superseded text is retained in the version record and is available on request at legal@bartendersnow.com.

2026-09-15 — We describe the open/click measurement used in our own email

Documents affected: Privacy Policy — new §8.4 (Email Tracking Technologies), §11.1 (Twilio SendGrid sub-processor row), §12.2 (Internet/Network Activity categories). Last Updated September 13, 2026 → September 15, 2026. The Effective Date does not move.

Classification: minor correction. It moves no fee, payout, cancellation, refund, dispute-resolution, or data-practice term, it is not adverse to any user, and it conforms the document to a practice already in place (our email provider's standard delivery/open/click measurement). The Terms of Service version is unchanged and no re-acceptance is required.

What the Privacy Policy said before. It disclosed that our email provider (Twilio SendGrid) processes "engagement data" and "email interaction logs," scoped the SendGrid row to "transactional email delivery, account notifications," and, in Section 8 ("Cookies and Tracking Technologies"), described cookies and web beacons on the website. It did not specifically say that the product-and-service (lifecycle) email we send contains an open pixel and click-tracked links.

What it says from this date. A new Section 8.4 explains that lifecycle email contains a small invisible image (a "pixel" or "web beacon") that measures opens, and links that route through our email provider so we can measure clicks; that we use this only to measure whether our own messages are delivered, opened, and acted on; that SendGrid processes it as a service provider; that we do not use it for cross-context behavioral advertising and do not sell or share it; and that turning off product-and-service email also stops the measurement. Section 11.1's SendGrid row and Section 12.2's category list are updated to name email open and click events.

Why it changed. We are turning on delivery/open/click measurement for our lifecycle email and are stating that plainly rather than relying only on the existing "engagement data" language.

Effect on Hosts and Bartenders. None to how any message is sent or how you turn it off. Unsubscribing from product-and-service email — the link in any such message, or your account settings — stops both the messages and their measurement. Transactional messages remain undisableable.

Prior text. The superseded Section 11.1 row and the pre-8.4 state are retained in the version record and available on request at legal@bartendersnow.com.

2026-09-13 — Product and service email is described as opt-out, which is how it has always worked

Documents affected: Privacy Policy §3.4 (Communications) and §7.2 (Communication Preferences), Last Updated September 12, 2026 → September 13, 2026. The Effective Date does not move.

Classification: minor correction. It moves no fee, payout, cancellation, refund, dispute-resolution, or data-practice term, it is not adverse to any user, and it conforms the document to a practice already in place. The Terms of Service version is unchanged and no re-acceptance is required.

What the Privacy Policy said before this date, in its own words. Section 3.4 grouped our non-transactional email under a heading "Marketing Communications (with consent)" — platform updates and new features, educational content and tips, promotional offers and incentives, and user surveys. Section 7.2 said, of email, "Marketing emails: Can be disabled via unsubscribe or account settings" and "Newsletter and updates: Optional subscription." The word "consent" read as a promise that we ask you to opt in before we send you any of this.

That did not match how the platform has always worked, and we are stating the correction rather than quietly swapping the text. We have never collected a separate marketing opt-in at sign-up. Product and service email — platform updates, tips, re-engagement reminders, our own offers, and surveys — has always been sent to registered account-holders by default, on the account relationship you started when you signed up, with a one-click unsubscribe in every message and an off switch in your account settings. That is an opt-out model, and calling it "with consent" over-stated the basis.

What it says from this date. Section 3.4 now describes this email as "Product and Service Communications (sent on an opt-out basis)", states that we send it to registered account-holders by default, and states that you can turn it off at any time through the unsubscribe link in any such message or in your account settings — and that doing so never affects the transactional messages that are necessary to run the service. A separate heading, "Newsletter and Third-Party Promotional Communications (with your consent)", keeps the true opt-in cases opt-in: a general-interest newsletter, and any message featuring a third party's products, are sent only if you affirmatively opt in. Section 7.2 is rewritten to match. Marketing SMS stays opt-in — nothing about text-message consent changes.

Why it changed. The stated basis should describe what actually happens. Aligning the policy to the opt-out model it has always followed removes an internal inconsistency (the policy already described email as opt-out in Sections 7.1 and 7.2) and lets us describe our first-party email accurately.

Effect on Hosts and Bartenders. None to how any message is sent or how you turn it off: product and service email was, and remains, on by default with a working unsubscribe, and transactional messages remain undisableable. What changes is only the description. Newsletters and any third-party promotional messages remain opt-in, and marketing SMS remains opt-in.

Prior text. The superseded Section 3.4 and Section 7.2 wording is quoted above. The full superseded text is retained in the version record and is available on request at legal@bartendersnow.com.

2026-09-12 — Planning-tool summaries disclosed before we start keeping them, and gated on your consent

Documents affected: Cookie Policy §2.2 (Last Updated August 21, 2026 → September 12, 2026) and Privacy Policy §2.2 and §5.1 (Last Updated September 7, 2026 → September 12, 2026). The Effective Date of each document does not move.

Classification: a minor correction plus a new disclosure, with a fresh cookie-consent request. Two different things happened here. The change to the Cookie Policy's Legal Basis line is a minor correction: it removes wording that could be read as saying nothing in this category ever needs a consent gate. The planning-tool summaries described in this entry are gated on your consent, and the line now says so. The paragraphs describing free planning-tool summaries are a new disclosure: they tell you about something we intend to start doing, before we start doing it — and as of this date we are not doing it yet. Because a stored summary of what you typed is a different kind of record from what this category previously described, we are asking for your Performance and Analytics choice again through the cookie banner on our marketing website. The Terms of Service version is unchanged, nothing in the app asks you to accept anything again, and no re-acceptance is required.

What these documents said before this date, in their own words. The Cookie Policy's Performance and Analytics category listed three kinds of data: pages visited and time spent on each page, browser and device information, and feature usage and conversion metrics. Its Retention Period line read, in full, "Used only for internal operational analytics" — a purpose with no period attached to it. And its Legal Basis line read "Business Purpose Exception (Cal. Civ. Code § 1798.140(e)); does not require a consent gate or opt-out." The exception is correctly cited, but the clause after the semicolon could be read as permission to record this category without asking you, and we do ask. The Privacy Policy described our first-party analytics and the coarse location it includes, and said nothing at all about our free planning tools.

What they say from this date. Both documents now describe a de-identified summary of each calculation you run with one of our free planning tools, such as the bartendersNow™ Stock List: the guest counts, the service duration, the occasion, the drinks you selected, any event date you gave us, the quantities the tool recommended, and the state and the first three digits of a ZIP code. They state what such a summary does not contain — no name, no email address, no account, device or session identifier, and no IP address — that we do not link it to you or to your device, and that we do not attempt to re-identify anyone from it. They state plainly that we never store a full ZIP code, a city name, a street address, or a precise device location in one. The Cookie Policy's Retention Period line now carries a period where it had none: an individual summary, and the aggregated counts derived from it, are kept for no longer than 24 months, and the Privacy Policy's retention section says the same in its own terms. The Legal Basis line now says that we gate these summaries on your consent — that we record one only where you have accepted the category through our cookie banner, and that we honor a Global Privacy Control signal.

Why it changed. The law we work to requires that you be told what we collect at or before the point we collect it, and we would rather publish a notice early than start a practice and describe it afterwards. We also narrowed what the notice promises before publishing it: an earlier draft of this disclosure described the region as a city or a five-digit ZIP code, and that was more precise than the purpose needs — for a low-volume event, a date and a five-digit ZIP can point at a household. So the published commitment is the narrower one: the state and three digits, and never a city name. Separately, the Legal Basis line needed fixing at the source rather than being worked around in the new paragraphs, because a sentence that reads as authority to drop the consent gate should not sit above a category we gate.

Effect on Hosts, Bartenders, and visitors. Today, none — we are not recording these summaries yet, and this entry is the notice that we intend to. What changes today is the cookie banner: because the Performance and Analytics category now covers a kind of record it did not cover before, our marketing website will ask for your choice on that category again, and a choice you made before this date is not carried across. If you decline the category, or your browser sends a Global Privacy Control signal, nothing about your calculation is recorded. If you accept it, then once we do begin, what is kept is the de-identified summary described above and nothing more — for no longer than 24 months. Nothing about a booking, a payout, a cancellation, or a fee changes on this date.

Prior text. The superseded Retention Period and Legal Basis lines are quoted in full above. The full superseded text of each affected section is retained in the version record and is available on request at legal@bartendersnow.com.

2026-09-08 — Our policies said Bartenders are never told about a Host's payment problem. They are told, when it cancels the booking.

Documents affected: Payment Failure Policy Section 6.2 (Version 1.5 → 1.6); Payment & Cancellation Policies Part 2, Section 6.2 and Part 4, Sections 8.2 and 8.3 (Version 1.12 → 1.13); Bartender Payout Policy Sections 8.2 and 8.3 (Version 1.5 → 1.6, Last Updated September 7, 2026 → September 8, 2026). All three documents were corrected in the same words on the same day. The two payment policies moved a version earlier the same day for the separate correction recorded in the companion entry below, and move again here — each published correction gets its own version.

Classification: minor correction. It moves no fee, payout, cancellation, refund, dispute-resolution, or data-practice term. It is not adverse to any user. It conforms these documents to a practice already in place. The Terms of Service version is unchanged and no re-acceptance is required.

What these documents said before this date, in their own words. The two host-facing payment policies ended their Bartender Payment Protection section with a flat statement: "Bartenders are not told about a Host's payment issues." The bartender-facing sections said the same thing from the other side: "We don't send you updates about a Host's payment problems. If a Host's payment isn't resolved, the booking simply doesn't confirm, or is cancelled — there's nothing for you to act on." And both documents told Bartenders, of a booking cancelled for non-payment, "You are not notified of the failed payment itself."

That was not accurate, and we are stating it rather than quietly swapping the text. When a booking is cancelled because a Host's payment could not be collected, we send the Bartender a notification headed "Booking Cancelled — Payment Issue" which tells them the booking was cancelled because the host's payment could not be collected, that they have been released, and that no payout applies. It also invites them to contact support if being released left them out of pocket. So the closing line "there's nothing for you to act on" was wrong twice over: it said we send nothing, and it told a Bartender there was nothing to do at the exact moment we were pointing them at support.

What they say from this date. The host-facing policies now say we do not share a Host's payment method or billing details with their Bartender, and that if a booking is cancelled because payment was not collected, the Bartender is told the booking was cancelled, that the payment was not collected, and that no payout applies. The bartender-facing sections say the matching thing: we do not pass on a Host's payment details or the steps they are taking to resolve a problem, and if a booking is cancelled for non-payment we tell you that, that the payment was not collected, and that no payout applies — and if being released left you out of pocket, contact support.

Read this narrowly, because we mean it narrowly. This says Bartenders are told when a booking is cancelled for non-payment. It does not say Bartenders are notified of a Host's payment problems generally. A payment difficulty a Host resolves inside the grace period is not announced to their Bartender, and a Host's payment details are still never shared.

Why it changed. A published statement about what our system does has to be true, and this one described a silence our software does not keep. The correction was made on all four sections across three documents at once, and in the same words, because the host-facing and bartender-facing accounts of the same event are deliberately kept aligned so they cannot contradict each other. Fixing one and leaving the others would have left our own policies disagreeing in public, which is worse than a uniform error.

Effect on Hosts and Bartenders. None. The notification described here has been sent since we stopped issuing payouts on non-payment cancellations; nothing about it changed on this date, and what changed is that these documents now describe it. If you are a Host who understood from these policies that your Bartender would never learn a payment had failed, that understanding was wrong, and you should read the corrected sections. If you are a Bartender who was told there was nothing to act on, there is: contact support if a cancellation left you out of pocket.

Prior text. The superseded sentences are quoted in full above and are retained in the version record, available on request at legal@bartendersnow.com.

2026-09-08 — Payment policies: a Bartender is paid on the normal schedule once their payout setup is finished

Documents affected: Payment Failure Policy Section 6.2 (Version 1.4 → 1.5, Last Updated September 4, 2026 → September 8, 2026) and Payment & Cancellation Policies Part 2, Section 6.2 (Version 1.11 → 1.12, Last Updated September 5, 2026 → September 8, 2026). Both documents carry this sentence, and both are corrected in the same words.

Classification: minor correction. It moves no fee, payout, cancellation, refund, dispute-resolution, or data-practice term. It is not adverse to any user. And it conforms these two documents to a condition already in force and already published elsewhere — Terms of Service Section 6.6, and Section 15 of the Bartender Payout Policy. The Terms of Service version is unchanged and no re-acceptance is required. Each policy's own version moves by one.

What these documents said before this date. Both describe what happens when a Host's payment fails and the Host resolves it inside the grace period, and both ended that line the same way: "standard process, and your Bartender is paid on the normal schedule." Stated without qualification, that was not accurate, and it has not been since completing payout setup became a step a Bartender takes separately from accepting work.

What they say from this date. The same line now carries the condition that has applied all along: a Bartender is paid on the normal schedule provided their payout setup is complete — and if it is not, their earnings are held for them and released when they finish. The money is not forfeited and it is not ours. It waits with our payment processor until the Bartender completes setup.

Why it changed. Neither of these is the document where a Bartender learns how they are paid; that is the Bartender Payout Policy, which has described the held-earnings condition since it was introduced. But both are read by Hosts, and both gave a Host an account of another person's payment timing that left out a condition we do apply. The right correction is to state the condition, not to keep a clean sentence that is incomplete. These two policies duplicate this section deliberately, so that they cannot disagree with each other; both were therefore corrected in the same words on the same day.

Effect on Hosts and Bartenders. None. Nothing about when or whether anyone is paid changed on this date — the condition described was already in force under the Terms of Service and the Bartender Payout Policy, and what changed is that these two documents now describe it. A Bartender who has completed payout setup is paid exactly as before. A Bartender who has not is in exactly the position they were in the day before: earnings held, and released on completion.

Prior text. The superseded sentence is quoted in full above, and is retained in the version record and available on request at legal@bartendersnow.com.

2026-09-07 — Security section corrected: the Privacy Policy said our messages were end-to-end encrypted. They are not.

Documents affected: Privacy Policy §2.2, §5.1, §5.2, §6.1, §11.1 (Last Updated September 6, 2026 → September 7, 2026; the closing line of Section 16 had been left at August 31, 2026 and now carries the same date as the header)

Classification: minor correction. No fee, payout, cancellation, refund, dispute-resolution, or data-practice term changed. None of the practices described below changed either — every one of them was already in place, and what changed is that the document now describes them correctly. That includes the coarse-location disclosure: the measurement it describes was already running, so disclosing it conforms the document to a practice already in place rather than announcing a new one. The Terms of Service version is unchanged and no re-acceptance is required. The Privacy Policy's own version moves from September 6, 2026 to September 7, 2026.

One of these corrections is uncomfortable, and it is named rather than buried. Removing a false statement that our messages were end-to-end encrypted is a minor correction by every element of the test above — it moves no operative term, and your position is identical before and after, because the practice never changed. But a reader who relied on that statement did rely on something we should not have published, and the remedy for that is disclosure, not a fresh click on an acceptance button. That is why this entry states what the policy said, in its own words, instead of quietly swapping the text.

What the Privacy Policy said before this date, and why it was wrong.

Encryption. Section 6.1 listed, as the first of our Technical Safeguards, "End-to-end encryption for sensitive data." That was not true, and we are stating it plainly rather than quietly deleting the line. End-to-end encryption means the provider cannot read the content; we can, and in narrow circumstances we do. It also could not have been true alongside a commitment we take seriously: our child-safety reporting obligations under 18 U.S.C. §2258A require us to read reported message content and report it to the National Center for Missing & Exploited Children. Those two statements cannot both stand, and the reporting obligation is the one that describes what actually happens.

Section 6.1 also claimed "Secure Socket Layer (SSL) for all transmissions" (accurate in substance, but SSL has been superseded by TLS and the corrected text names TLS), "Regular security audits and vulnerability assessments," and "Multi-factor authentication for administrative access." The last two described controls we could not substantiate, so they have been removed rather than reworded.

Administrative and physical safeguards. Section 6.1 claimed "Regular security training for employees" — Midnight Logic has no employees; it is founder-operated. It claimed "Incident response procedures and breach protocols" — we do not have a written breach-response runbook, and we are not going to publish a claim that we do while writing one. And under a heading describing our physical safeguards it listed "Secure data centers with restricted access," "Environmental controls and monitoring," and "Secure disposal of hardware and storage media." We operate no data centre and dispose of no storage media; that security is provided by our cloud provider, and the corrected text says so.

Analytics retention. Section 5.1 said analytics data was "Anonymized and retained for platform improvement," and Section 5.2 said "Some information may be retained in anonymized form for analytics." Neither was accurate. Our analytics event records carry your account and device identifiers for as long as we hold them, and we run no process that anonymizes them. The second sentence was also an open-ended exception to your right to have information deleted, which is not what we do.

One-time codes. Our sub-processor table (Section 11.1) attributed "SMS multi-factor authentication (OTP)" to Twilio. All three parts of that were wrong: the code we send you is an email, not an SMS; it is delivered by SendGrid; and it verifies your email address when you sign up — it is not a second factor when you log in.

Analytics location data. The table's Google Analytics row did not disclose that our analytics measurement includes coarse location.

What the Privacy Policy says from this date.

Encryption. Section 6.1 now describes the protections that actually exist: every connection uses HTTPS with TLS and we require it; stored information is encrypted at rest with AES-256 keys managed by our cloud provider; your card details are tokenized by Stripe under the PCI Data Security Standard and we never store your full card number; and access to systems holding personal information is limited by role, with access to the content of your messages additionally requiring an open, linked abuse report and being written to an audit log. It then states affirmatively that the Platform is not end-to-end encrypted, that encryption in transit and at rest protects your information from outsiders and from other users but does not put it beyond our own reach, and that we will access message content where the law requires it — including our child-safety reporting obligations.

Administrative and infrastructure. Section 6.1 now says only what is true: access to personal information is limited to what a person needs to do their work; personnel and contractors are subject to confidentiality obligations and access controls, with background screening where appropriate and permitted by law; we keep a record of administrative access to message content; and the physical security of the facilities where your information is stored is provided by Google Cloud Platform under its own security programme, not by us.

Analytics retention. Sections 5.1 and 5.2 now say that individual analytics event records are linked to your account and device identifiers while we hold them, that they are not anonymized, and that they are scheduled for deletion 90 days after they are recorded, whether or not your account is active. Aggregated counts — totals that contain no account, device, or session identifier and cannot be traced back to you — are kept after the underlying records are deleted, we keep them only in aggregated form, we do not attempt to re-identify anyone from them, and we require anyone who receives them from us to do the same. We do not otherwise keep an anonymized copy of information you asked us to delete.

One-time codes. The Twilio row now describes what Twilio actually does — operational SMS alerts about your bookings, where those are enabled — and the SendGrid row now names the delivery of the one-time codes used to verify your email address.

Analytics location data. The Google Analytics row and a new paragraph in Section 2.2 disclose that our measurement includes coarse location — the state, the city, and the first three digits of a ZIP code — used to understand where our services are being requested, including areas where we are not yet available. We do not send Google Analytics your full ZIP code, your street address, or precise device location such as GPS coordinates, and we do not use this measurement for advertising.

Effect on Hosts and Bartenders. Nothing about how the Platform handles your information changed on this date; the description of it did. Concretely: your messages were never end-to-end encrypted, so nothing about them is less protected today than it was yesterday — but if you had understood from Section 6.1 that we could not read your messages, that understanding was wrong, and you should read the corrected Section 6.1 before deciding what to put in a message. Your rights are unchanged, including your right to ask us to delete your personal information.

Why it changed. A security representation in a privacy policy has to be true. These were not, and they described a company and a set of controls that do not exist. Publishing a list of security measures is voluntary — nothing requires it — so an inaccurate item on that list is all downside, and the right correction is to narrow the list to what we can stand behind rather than to soften the wording.

Prior text. The superseded text of each affected section is retained in the version record and is available on request at legal@bartendersnow.com.

2026-09-07 — Automated screening of uploaded images disclosed; the automated-decision opt-out line corrected

Documents affected: Privacy Policy (Last Updated August 31, 2026 → September 6, 2026) §§3.2, 4.2, 11.1, 12.1, 12.3

Classification: a minor correction plus a new disclosure. Two different things happened here. The change to the automated-decision line is a minor correction: it moves no fee, payout, cancellation, refund, dispute-resolution, or data-practice term, and it replaces a statement that was not accurate with one that is. The additions describing automated image screening are a new disclosure: they tell you about something we are starting to do, before we start doing it. Neither changes the Terms of Service, whose version is unchanged, and neither asks you to accept anything again. The Privacy Policy's own version moves from August 31, 2026 to September 6, 2026.

What this document said before this date. It described how we use and share your information without mentioning that images you upload are screened by an automated tool before they are shown publicly. Its sub-processor table named Google Cloud Platform / Firebase for hosting, database, authentication and push notifications, and did not name profile photographs among the data categories that provider processes. And under Right to Opt-Out, it listed a right to "opt out of profiling for automated decision-making" — a right we published without ever building a way for you to use it.

What it says from this date. That we screen images you upload for explicit or violent content, using automated tools, before they are displayed publicly — stated in the section on how we use your information, in the section on who we share it with, in the sub-processor table (naming the provider and adding profile photographs and other uploaded images to the data categories), and in the sensitive-information section. A footnote to that table states that the screening classifies an image only: it identifies nobody, analyses no facial geometry, creates and stores no biometric template, that under the provider's terms the images are not used to train the provider's models and are deleted after processing, that we keep only the outcome, and that a photo the automated screen flags is reviewed by a person before any decision is made.

The opt-out line is replaced with what is actually true: we do not use automated decision-making to make decisions producing legal or similarly significant effects concerning you; no automated tool decides whether you may use the platform, appear in search, be booked, or how much you are paid; and if we ever use automated decision-making for a decision of that kind, we will give you notice and a way to opt out before we do.

Why it changed. The automated screen is new, and a sub-processor table that names each provider's function and data categories has to name this one. The opt-out line was the more serious problem: it published a right with no mechanism anywhere in the product, so it promised something we could not deliver. Removing it is not a reduction of what you can actually do — nothing was ever there to use — and it is replaced by a statement of what we do not do, plus a commitment to give notice and a real opt-out before that ever changes.

Effect on Hosts and Bartenders. From this date, a photo you upload goes through an automated check for explicit or violent content before it appears publicly, instead of waiting for a person to look at it — so most photos will appear sooner. A photo the automated check flags is still looked at by a person, and every decline and take-down remains a human decision. This is a content check: it does not confirm that a photo is of you, and it is not identity verification.

Prior text. The superseded text of each affected section is retained in the version record and is available on request at legal@bartendersnow.com.

2026-09-05 — Payout field labels corrected: a booking's service total is not your "gross earnings"

Documents affected: Bartender Payout Policy (Version 1.3 → 1.4) §§1, 3.1–3.3, 6.2, 7.1–7.2, 10.1–10.2 · Payment & Cancellation Policies (Version 1.10 → 1.11) §§1, 3.1–3.3, 6.2, 7.1–7.2, 10.1–10.2

Classification: minor correction. No fee, payout, cancellation, refund, dispute-resolution, or data-practice term changed. Every dollar figure, percentage, cancellation tier, and payout timing commitment in these documents is unchanged. The Terms of Service version is unchanged and no re-acceptance is required.

What these documents said before this date. That the full price of a booking was your "gross earnings," that our 12% fee was "deducted from" those earnings, and that what reached you was your "net payout." Those three labels appeared in the Key Principles, in the payout formula and both worked examples, in the cancellation and Captain examples, and in the payout receipt and year-to-date dashboard summary described in Section 10.

What they say from this date. The full price of a booking is the "gross service total" — a figure for the job, not a statement of what you earned. Our "platform fee" is retained before your payout, rather than deducted from your earnings. What reaches you is "your payout." This is the same vocabulary your event earnings screens in the app already use. A sentence added to the payout-receipt section explains that your payout counts toward the total reported on your Form 1099-K, that the platform fee is never settled to you and so is not part of that total, and that it is not a further deduction against it.

Why it changed. Our 12% fee is retained before any payment is made to you, so it is never money that reached your account. Calling the pre-fee figure your "earnings," with our fee "deducted" from them, described a payment structure we do not use — and it contradicted the Form 1099-K correction published in the entry below on 2026-09-04, which these documents were meant to match. The labels now say the same thing everywhere.

Effect on Bartenders. None on what you are paid. Your payout is 88% of your service total plus 100% of your tips, on the same schedule, under the same cancellation tiers, with the same rights: the words changed and the money did not. Every worked example keeps its original figures — $400 minus $48 leaves $352; $480 minus $57.60 leaves $422.40; a 50%-tier cancellation of $200 minus $24 leaves $176; a $50 Captain fee minus $6 leaves $44.

Prior text. The superseded text of each affected section is retained in the version record and is available on request at legal@bartendersnow.com.

2026-09-04 — Form 1099-K reporting basis corrected

Documents affected: Terms of Service §6.2 · Bartender Payout Policy §11.3 · Payment & Cancellation Policies §11.3

Classification: minor correction. No fee, payout, cancellation, refund, dispute-resolution, or data-practice term changed. The Terms of Service version is unchanged and no re-acceptance is required.

What these documents said before this date. That amounts reported on IRS Form 1099-K would reflect the total gross service allocations facilitated through the platform prior to platform fee deductions — that is, a Bartender's service total before our 12% fee.

What they say from this date. That reported Form 1099-K amounts reflect the total gross amount settled to the Bartender's connected payout account — the 88% settlement payout, 100% of in-app tips, and any cancellation payout or labor-overage distribution paid the same way. The Host Marketplace Fee and the Platform Retained Fee are not settled to the Bartender and are not included.

Why it changed. The earlier wording described a payment structure we do not use. Our fee is retained before any distribution to a Bartender, so it is never part of a payment made to a Bartender and cannot be reported as one. The corrected wording matches how Bartenders have always been paid and how our reporting has always been configured.

Effect on Bartenders. None on what you are paid: 88% of your service total plus 100% of your tips, on the same schedule, unchanged. Your taxable income is also unchanged — the corrected figure simply excludes a fee that was never paid to you and that you would not deduct.

Prior text. The superseded text of each affected section is retained in the version record and is available on request at legal@bartendersnow.com.