Privacy Policy

Effective September 27, 2026

The short version

• We collect what Flock needs to work: your account, your plans, your messages.
• Location is used only while you're using the app. Never in the background.
• We don't sell your information, we don't share it for advertising, and we don't run ads.
• Budget amounts are never shown to other people. The group only sees a shared ceiling.
• Photos you upload have their hidden camera data, including any GPS fix, removed before we store them.
• Two features send text to Google's Gemini: Birdie, the assistant in the app, and Roost, the advisor for venue owners. Each has its own paragraph below saying exactly what leaves.
• A few venues have a Flock sensor at the door. It counts bodies and cannot identify anyone. Section 3 says exactly what it measures.
• You can delete your account from inside the app. It's a real delete, not a deactivation.

The full detail is below. It's written in plain language on purpose. If anything is unclear, email social@flockcorp.com.

Who we are

Flock is a social coordination app that helps you plan nights out with friends. Flock ("we", "us", "our") is operated by Flock Social LLC, a Pennsylvania limited liability company. We are the data controller for personal information processed through the Flock app, flockcorp.com, the venue dashboard, and the venue sensors described in section 3.

This policy covers all of those. It applies whether you use Flock in the iOS app or in a browser, whether you have an account or answer an invite link as a guest, and whether you use Flock to make plans or to run a venue. Write to us at social@flockcorp.com. Our postal address is 2610 Long Ridge Dr, Hellertown, PA 18055.

What we collect

You provide directly

• Account info: email, password (stored as a one-way hash, we never see your password), display name, optional avatar, optional short bio. We send a link to your email at sign-up to confirm it's really yours. Your friend code is made at random the first time you ask for it and stored with your account, so nobody can work it out from your account number.
• Phone number (optional): sign-up never asks for one. You can add a phone number later from your profile. It is not used to find you unless you turn on "Let friends find me by my phone number" in Settings, which is off until you turn it on. Adding a number requires confirming your password or a recent sign-in, and turning discovery off erases the code we match against.
• Contacts you choose to match (optional): if you use "Add friends" from your phone contacts, only phone numbers are sent, never names or anything else on a contact card. We turn each one into a one-way keyed code and compare it with the codes of people who chose to be findable by phone. We run the lookup and don't store those numbers, and a number belonging to someone who is not on Flock leaves nothing behind.
• Year of birth: collected at sign-up so we can confirm you're 13 or older. We ask for the year only. The check runs on our server, which works out your age from that year in the one way that can only ever count you as younger, so nobody under the minimum gets through on a rounding. Accounts created before 15 September 2026 gave a full date of birth, and an older account that never gave one is asked for the full date the next time it signs in; either is used for the same age check and for nothing else.
• Your acceptance of the terms: we store the moment you agreed to the Terms of Service, so both of us know what you agreed to and when.
• Interests: the tags you pick on your profile, such as live music or trivia. They are kept on your device and synced to your account so a second device agrees with the first.
• Trusted contacts: if you add emergency contacts, we store the name, phone, email, and relationship you give us. Your trusted contacts get SOS alerts by email only. If you stand an alert down, an all-clear email goes to exactly the contacts your alert reached, including through any update to it, and it carries no location. We store the phone number because the form asks for it and you may want it on file, but nothing in Flock texts or calls it.
• Messages and content: flock chat messages, direct messages, emoji reactions, images you upload, venue reviews you write.
• Plans and votes: flocks you create or join, RSVPs, venue votes, budget submissions, check-ins (including NFC taps at a venue), and the venues you pin or vote on inside a direct message.
• Your calendar entries: anything you add to your Flock calendar (title, venue, date, time) is stored on our servers so it is there on your next device. It is yours alone; nobody else is shown it.
• Availability status: if you set "down tonight" or similar, we store that status, the note you attach, and when it expires. Your friends can see it until it expires or you clear it.
• Crowd reports: when you tell us how busy a venue actually is, we store that report with your account, the venue, and the time. We use it to correct our crowd predictions and to train the model that makes them. Other people see the corrected prediction, never that you were the one who reported.
• Reports and blocks: if you report content or block someone, we store what you reported, who you blocked, and what we did about it. Blocking is mutual, and it also ends the friendship if you had one.
• Guest RSVPs: if someone opens a flock invite link without a Flock account, we store the display name they type, the venues they vote for, and the budget amount they enter if they choose to share one, tied to a random link token. Like a member's, that amount is never shown to anyone else. No email, no phone, no account is created for them.
• Bill splits: if your group splits a bill, we store the total, the tip, who paid, each person's share, and whether a share has been marked settled. The people in that flock see it. No money moves through Flock: paying someone back happens in Venmo, Cash App, or Zelle.
• Payment handles (optional): if you add them for bill-splitting, we store your Venmo username, Cash App cashtag, or Zelle identifier so flockmates can pay you back. These are usernames and handles only. Flock never collects or processes card, bank-account, or payment-card numbers.
• Venue owner details (optional): if you claim a venue, we store the business profile you fill in, the operating facts you tell us, and the promotions, events, occupancy readings and replies you post. That has its own section below, Venue owners and business data.
• Waitlist email: if you enter your email on flockcorp.com to hear when Flock launches, we store that address and send you one confirmation. It is not linked to any Flock account, we do not sell it, every message carries an unsubscribe link, and we will delete it if you ask us at social@flockcorp.com.
• Sign-in tokens: if you sign in with Apple or Google, we receive an identity token from the provider, verify it, and issue our own session token. Apple accounts have one extra piece: Apple's rules say deleting your Flock account should also revoke Flock's access to your Apple ID, and doing that needs a refresh token from Apple that we store for that single purpose. When you delete your account, we use it to revoke Flock's access to your Apple ID, and the token is deleted with the rest of your data. After that, Flock no longer appears under Sign in with Apple in your Apple ID settings.

Photos, and what is hidden inside them

A photo from a phone carries more than the picture. The file can hold the exact spot it was taken, accurate to a few metres, the make and model of the camera, the moment of capture, and on many cameras a small copy of the original frame from before you cropped it. None of that shows up in any app, so nobody knows they sent it.

Before we store an image you upload, our server strips that hidden data out. It covers avatars, chat photos and direct message photos, in JPEG, PNG and WebP, which is what phones produce. What comes off is the EXIF, XMP and IPTC blocks: GPS position, device identifiers, capture times, embedded thumbnails, and free-text comments. What stays is the colour profile, because dropping that changes how the picture looks. The picture itself is not re-encoded, so nothing about its quality changes. If a file does not parse the way its format says it should, we store it unchanged rather than risk corrupting it, and we do not claim to have cleaned it.

Every image is also screened against our content rules before anyone can see it. That check is described under Who we share with and in our Community Guidelines.

We collect automatically

• Product analytics: we use PostHog. The detail, including the long list of things we have switched off, is in Analytics, error reports, and email.
• Push notification tokens: if you enable notifications, we store the device token issued by Apple Push Notification service or Firebase Cloud Messaging.
• What we showed you: when the app shows you a crowd prediction for a venue, we record the venue, the number we published, which model produced it, and when. That record is what lets us check the prediction against what you or the venue later reported, which is how the model gets better. It is tied to your account and kept for 180 days.
• Check-ins: a check-in inside the app is stored with your account and the venue. A tap on an NFC tag at a venue while you are signed out is stored with the venue and no account at all.
• Reliability: when a plan ends, the host can mark who turned up. We keep a running score from that on your account, and the people in a flock with you can see it. It is a number about attendance and nothing else.
• On-device storage: your browser or app keeps your sign-in token, your display preferences (theme, map style, the order of your flocks), your interests, and your last known coordinates so the map opens where you are. Those coordinates stay on the device. PostHog keeps its identifier in local storage rather than in a cookie, so no analytics cookie rides on requests and clearing site data removes it.
• Connection metadata: your IP address is used for rate limiting and to spot abuse. It appears in our server logs. Three places also write it to the database. The record of an email verification link, so we can limit how many verification emails one address or one network can trigger; those are deleted when your account is deleted. The record of a password reset request, which holds the requesting address next to a one-way hash of the email and is deleted after 7 days. And the record of a password reset link, which holds the requesting address next to your account number and the email address the link was sent to, in the clear, so that a link cannot keep working after you change your address. That third record is deleted with your account, and separately once the link is spent or expired and old enough that nothing needs it.

Location

• Live location share in a flock: only when you explicitly turn it on inside an active flock, and only while you leave it on. Your coordinates are passed straight through our server to the other members of that flock and are never written to our database, so there is no trail of where you were. Blocked accounts are excluded from the hand-off. You can stop it at any time.
• Live location share in a direct message: the same thing, one to one. It reaches only the person you are talking to, only while you leave it on, only if the two of you are connected, never anyone either of you has blocked, and it is not written to our database either.
• SOS: when you press SOS, we email your trusted contacts, with your location when your phone can find one. We also alert people in the app, as a notification and on screen: those who, like you, have accepted a confirmed plan that starts within twelve hours of that moment, before or after, other than anyone banned from Flock and anyone you have blocked or who has blocked you. Their alert carries the same location when the alert has one. We store that alert (your account, the coordinates, how many contacts were emailed, who it reached, and when you stood it down) so there is a record of what happened and so an all-clear goes back to the people it reached. The all-clear in the app leaves out anyone who has since been banned, or who has since blocked you or been blocked by you. It is deleted with your account. You can also send your trusted contacts your location without an SOS, from the Safety screen; that sends the same kind of email and is not stored. We never collect background location: Flock only reads your location while you are using it.
• Map, venue search, weather, events, and crowd levels: your device location centers the map on the device itself. When you search for venues, load the weather, look for events nearby, or ask Birdie for somewhere close, your coordinates are sent to our server so it can run that lookup, and the search area, not your account, goes on to Google Places, OpenWeatherMap or Ticketmaster. We do not store those coordinates in our database and we do not build a location history from them.
• Coordinates stay out of analytics: a few of those lookups carry your position inside the web address they request. Anything shaped like a coordinate is replaced with the word "redacted" before any analytics or error report leaves your device, in the address, in the referrer, in breadcrumbs, and in performance traces. A place name you typed is left readable, because a place name is not a position.

Anonymous budget data

Budget submissions are stored on our servers but the system is designed so individual amounts are never returned to other flock members. Until the budget settles, the only things other members see are counts: how many have answered, how many are in the flock, and whether it is ready. No number at all. The budget settles when every member who has accepted the plan and every guest who said they are in from an invite link has answered, and at least three members have shared an amount (a guest's amount goes into the figure but does not count toward the three). The person who created the plan can settle it sooner by locking it, which also needs three members' amounts and closes it to anyone who has not answered yet. Only when it settles is a single group figure published, and what is published is a rounded-down band rather than anyone's actual figure. It is published once and never moves, because a ceiling is a minimum and a number that moved when the fourth person answered would name whoever has the least. This is a core product guarantee enforced in code.

Venue occupancy sensors

A venue can install a small Flock sensor near its entrance. It is the only part of Flock that is hardware, and it measures the room rather than the people in it. This section applies to everyone who walks into a venue that has one, whether or not you use Flock.

What the sensor sends us

Every 30 seconds it sends these numbers, and nothing else:

• Doorway crossings: how many times someone crossed the doorway since the last reading, in either direction. Depending on the unit, it counts them with an infrared beam across the doorway or with an infrared distance sensor that looks down at it.
• Warm bodies in view: a count of the people in a grid of 19,200 temperature readings, worked out on the device. A small counting model marks each person. It was trained on more than two million thermal images, none of them from a Flux sensor, and it names kinds of things, never who anyone is. A device without the model counts heat clusters instead.
• Estimated people inside: the doorway count and the warm-bodies count combined on the device into one number with a likely range, and how long people typically stay. These are counts, worked out on the device.
• Ambient loudness: one loudness level, the typical level over the last minute.

What it does not do

• No photo or video. The thermal part is a 160 by 120 grid of temperatures, not a picture. It is reduced to a count on the device and thrown away. It is never stored and never sent to us. A doorway distance sensor, on a unit that has one, reads 64 distances, an 8 by 8 grid in which one square is about 30 cm of floor. Each reading becomes a crossing count on the device and is thrown away too.
• No audio recording. The microphone's samples become a single loudness figure every half second and are discarded on the device. No sound is stored, buffered, or transmitted, and speech cannot be recovered from a loudness level.
• No phone detection. No wifi or Bluetooth scanning, no MAC addresses, no beacons. Nothing reads a device in anyone's pocket.
• No identity. The sensor counts bodies. It cannot tell one person from another, it cannot tell whether you have a Flock account, and it does not know who you are.

A reading is filed against the venue and the sensor that sent it, and it holds nothing else: no name, no account, no phone or device belonging to anyone in the room, nothing that separates one person from the next. So there is nothing in one to trace back to you.

What we do with the readings

They produce the "Live Occupancy" figure and the 12-hour chart on that venue's page in the app, and the same figures in that venue owner's dashboard. We keep them as a record of how busy the venue has been over time. Because they contain no identifiers, deleting your Flock account does not touch them and there is nothing in them belonging to you to delete. We do not currently delete them on a schedule.

The occupancy card also shows how many Flock accounts checked in at that venue in the last hour. That is a count of separate accounts. No names go with it.

If we ever put anything in this device that can tell one person from another, this section is rewritten before the device goes in.

How we use your information

• Operate the core product: accounts and sign-in, flocks, chat, voting, budgets, bill splits, the calendar, notifications.
• Show you crowd predictions, venue details, weather and nearby events for the area you are looking at.
• Send transactional email (email verification at sign-up, password resets, SOS alerts) through Resend.
• Send push notifications you opted into, including the crowd alerts for a plan you have confirmed.
• Answer questions in Birdie, and answer venue owners' questions in Roost. Both are described in Birdie and Roost.
• Improve our crowd forecasts. Crowd reports people submit at a venue correct the live prediction for that venue and go into the data the model is retrained on. Venue owners' occupancy readings do the same. Sensor readings are described in section 3.
• Screen text and images against our content rules before they are stored, and act on reports of content and behaviour that break them.
• Keep the service up: monitor reliability, diagnose errors, rate limit, and stop abuse, spam and account takeovers.
• Understand how Flock is used, at the level of counts and events rather than content.
• Comply with legal obligations, including child-safety reporting.

We do not sell your personal information. We do not share it for cross-context behavioural advertising. We do not run ads, and we do not use your messages or your content to train advertising models, ours or anybody else's.

Our legal bases

If you are in the EEA or the UK, the law wants us to say why each kind of processing is lawful. Here it is, plainly.

• Performing our agreement with you: your account, your flocks, chat and direct messages, votes, RSVPs, budgets, bill splits, the calendar, venue search, crowd predictions, the venue dashboard, and the transactional email that keeps an account working. Without these there is no product to deliver.
• Your consent: location, push notifications, access to your photo library or camera, matching your phone contacts, the waitlist email, and every analytics event described in Analytics, error reports, and email, the page views and the hand-written events tied to your account number alike, none of which run until you agree and none of which leave a gap if you decline. Each of those is asked for and each can be withdrawn, in your device settings or by clearing the thing you set. Withdrawing consent does not undo processing that already happened.
• Our legitimate interests: keeping Flock safe and working. Rate limiting, abuse and fraud prevention, moderation and the records it produces, error monitoring, and improving the crowd model from reports people choose to file. We have weighed these against your interests, which is why the analytics are configured the way Analytics, error reports, and email describes and why the model's training data carries no account identifiers.
• Legal obligation: responding to lawful requests, and reporting apparent child sexual abuse material to the National Center for Missing and Exploited Children or the relevant authority.
• Vital interests: the SOS feature. When you press it, we email your trusted contacts, and alert in the app the people on a plan with you that the SOS entry above describes, with your location when your phone can find one, because you are telling us something is wrong.

Where we rely on legitimate interests, you can object. See If you are in the EEA or the UK.

Birdie and Roost

Flock has two features that send text to a large language model. Both use Google's Gemini API. They are separate features with separate audiences and separate payloads, so they get separate paragraphs. Neither one has any ability to write to your account, post on your behalf, or change anything. They read and they answer.

Birdie, the assistant in the app

When you chat with Birdie, what goes to Google to produce the reply is your first name, your age bracket (under 18, under 21, or adult, never your birthday), your messages in that conversation, and, only if you have allowed location, your approximate position rounded to about a kilometer.

Every message also carries where you are in the app, because otherwise Birdie cannot answer "is this place busy". That means the screen and tab you are on and, when you have one open, the name of the flock you are looking at with its venue and status, and the name of the venue you are looking at with its Google place identifier. This goes with every message, not only when you ask about a plan.

On top of that, if you ask Birdie about your plans or your friends, the names, venues and times of your flocks and your friends' display names are included so it can answer. When Birdie looks up a venue, the venue and the crowd numbers we hold for it go with the question.

What is not sent: we don't send your email, exact coordinates, or messages from your flocks or your direct messages. The roster of who is in a flock is replaced by a count. Birdie conversations are not used by us for advertising and we do not use them to train any model of our own. What Google may do with the text it receives is governed by Google's own terms for the Gemini API.

Birdie's answers are generated. They can be wrong. Nothing Birdie says is advice about your safety, your health, your money, or the law.

Roost, the advisor for venue owners

Roost is the product venue owners will pay for, and it works two ways. You can tap one of the suggested questions, or you can type your own question about your business.

When you tap a suggested question, what goes to Google is the identifier of that question and a block of facts our server has already computed about your venue: things like your projected peak hour, your own recent occupancy readings, the operating facts you gave us at intake, the weather, the ticketed events listed near you, and where your venue sits inside its cohort. The model's only job there is wording. Every number in the answer is put back in by our server afterwards, and an answer that contains a number the model wrote is thrown away unread.

When you type your own question, the question itself goes to Google as well, inside the same request. It is capped at 280 characters and stripped of control characters first. It is used to route your question and, where the answer is general trade advice rather than a reading of your own numbers, to write that advice.

What Roost does not send: nothing about any Flock user. No consumer's name, account, message, budget, or position. No other venue's identity or figures. The cohort comparison your answer may draw on is an aggregate, and it is only computed once two floors are cleared: five reporting owners besides you, and three of their readings landing on the number itself. See Venue owners and business data.

What Roost stores: not your question. We keep counts, how many questions your venue asked today and how many tokens they cost, so we can meter the feature. The text of a typed question is not written to our database.

Roost is an analyst, not an oracle. Every figure it quotes carries its source and its date. Where our data cannot answer, it refuses instead of guessing. Predictions are estimates. Nothing Roost says is a guarantee about how your business will do, and nothing it says is legal, tax, employment or financial advice.

Venue owners and business data

Venues appear on Flock whether or not anybody claims them, because listings are built from public sources such as Google Places and from what Flock users post. Claiming a venue does not create the listing; it gives you tools to manage your side of it. This section is about what we collect from the person and the business behind a claimed venue.

A venue account is an ordinary Flock account, so everything above applies to it too. On top of that we store:

• Your business profile: business name, category, location, description, phone, operating hours, logo or photo, goals, and the Google place your venue corresponds to. This is shown publicly in the app.
• Operating facts you tell us: when the kitchen stops, your capacity, how long a table usually turns, your age policy, your reservation policy, the largest walk-in group you take, your typical spend per person, what you believe your busy nights are, and what sits near you that pulls a crowd. Google's opening hours describe your door, not your pass, so this is the only place these facts exist. We use them to answer your own questions and to give groups useful answers about your venue. They are not features in the crowd model.
• Occupancy readings you post: the 0 to 100 slider. Every reading is stored with your account, your venue, and the time. It is shown to users as coming from your venue, never as Flock's own estimate. The wording that carries it is ours, built from your venue's category rather than from anything you typed, and it expires by itself 90 minutes after you set it. You can retract one. Retracted and expired readings are not deleted, because a labelled observation of a venue-hour is exactly what the crowd model learns from, which is the other half of why this feature exists.
• What you post to your listing: promotions, events, and replies to reviews. Public, and screened by the same moderation rules as anything else.
• Records about your account: your tier, any comped tier we granted, whether the weekly digest is switched on, and the digest sends we have made.

What we do with what you submit

Your occupancy readings do three things. They set the live number users see at your venue while they are fresh. They become training labels for the crowd model, which serves every venue, not only yours. And once enough venues in one city and category are reporting, they contribute to a cohort figure that answers the question every operator asks: was it just us, or was everyone slow.

That cohort figure is built so that no venue's own number can be read out of it, and it has to clear two floors before it is published at all. First, at least five reporting owners other than the one asking must have posted into the same city, category, night and hour band. We count owners rather than venues so that one company with five rooms cannot become five voices. Second, at least three of those owners' readings must round to the very number we are about to print, so the number describes several businesses rather than sitting on top of one. Both are higher floors than we use anywhere else, because a venue is a pin on a public map with a name and an address and the set of them is short enough to count.

The asking venue is inside the group its own figure is drawn from. Leaving it out would make the number change depending on who asked, which is its own way of leaking. The figure itself is the middle reading of that group, rounded to the nearest ten, so it is not read off any single venue exactly: we pick the middle reading rather than averaging the two either side of it, precisely so that no arithmetic connects the published number back to one reading. The most anyone can learn about another venue's reading is which rounded step it fell near. When either floor is missed we say so and give no number, and we do not say which floor it was, because that would itself describe who reported.

Readings are accountable in the other direction too. When three or more verified users in the room contradict a live owner reading by a wide margin, we mark it, and repeated divergence suspends the override for that venue so users see our own estimate again.

What venue owners see, and do not see

The dashboard shows counts and curves built from Flock activity: how many groups considered the venue, check-in counts, predicted busyness, review text that is already public. It never shows individual users' identities, their budgets, their positions, their messages, or who voted for what. The advisor that reads this data is structurally forbidden from touching budgets at all.

Roost, the paid venue plan, is bought on flockcorp.com. Stripe takes the payment, and we never see or store the card. What it costs, and when a venue can be charged, is under Venue fees in our Terms of Service.

Who we share with

We share information only with the companies that help us run Flock, and only as much as the job needs. This is the whole list, taken from the dependency inventory the codebase keeps of every outside service Flock touches. Each entry says what that company receives.

They run Flock itself

• Railway hosts our server and our PostgreSQL database. Everything described in this policy that is stored is stored there. Railway's Postgres also writes a continuous backup to object storage.
• Vercel hosts flockcorp.com and the web build of the app. It sees the requests your browser makes for the site, including your IP address.

They receive something about you

• Resend sends our email. It receives your email address and the contents of the message: the verification link, a password reset, an SOS alert (with your location when it has one), the waitlist confirmation, the Monday venue digest. It also tells us when an address bounces or someone marks a message as spam, which is how our do-not-mail list gets written.
• Apple Push Notification service and Firebase Cloud Messaging deliver push notifications. They receive the device token and the notification.
• Google Cloud Vision screens every image you upload against our content rules before anyone can see it. The image is sent for that check and for nothing else. If the check cannot run, the upload is refused rather than let through.
• Google Gemini powers Birdie and Roost. Birdie and Roost says exactly what each of them sends.
• PostHog receives product analytics events tied to your account number, and the IP address the request arrives from. It also receives the cost and speed measurements behind Birdie: token counts and latency, never the words. See Analytics, error reports, and email.
• Apple and Google verify sign-in identity, only when you choose those options. Apple additionally receives the revocation call when you delete an account you created with Sign in with Apple.
• MapTiler and CARTO serve the map tiles. Your device loads tiles from them directly, so whichever one is in use sees your IP address and the area of the map you are looking at. It does not see your account.
• DiceBear serves the default avatar for an account with no photo. Your device loads that image directly, so it sees your IP address and nothing else.
• RevenueCat keeps the record of who has Flock Pro, wherever it was bought. In the iOS app, if the RevenueCat key was compiled into that build, Flock tells RevenueCat your account number when you sign in, whether or not anything is for sale. On the website its code is never loaded; a purchase made there reaches RevenueCat from Stripe, labelled with your account number. For an App Store purchase it receives the receipt Apple issues, and for a web purchase the Stripe subscription record, and nothing else. Your card details never reach us or RevenueCat.
• Stripe takes the payment when you buy Flock Pro on flockcorp.com. It receives your email address and name, the card or wallet you pay with, which you enter with Stripe directly, and, where sales tax applies, your billing address. We keep only the reference that links your Flock account to your Stripe customer record, so you can manage the subscription and so deleting your account cancels it. Nothing reaches Stripe unless you start a purchase on the web.
• Cloudflare runs our domain's DNS and the mailbox behind social@flockcorp.com, which it forwards to the inbox we read. Every message you send us passes through it: a request to see your data, a deletion request, a complaint, a child-safety report, a copyright notice. It receives the address you write from and everything you put in the message. This page names it because a data-protection request that arrives by email is handled by whoever carries the email.
• Sentry would receive crash and error reports. It is wired up and switched off. Analytics, error reports, and email says what would happen if it were turned on.

They receive a place or a search, not a person

• Google Places returns venue search results, venue details, nearby venues for a venue owner's competitor view, and venue photos. We send the search text and the map area, never your account.
• OpenWeatherMap returns the weather for an area, which the crowd model reads as an input. No personal information is sent.
• Ticketmaster returns ticketed events near an area, which the crowd model also reads. We send the search area, not your account.

They receive nothing about anyone

• BestTime is where the crowd model's training corpus comes from. Collection stopped in May 2026 and started again on 1 September 2026. It runs as a scheduled job that reads public busyness figures for venues, it sends nothing about you, and no part of the running product calls it.
• SeatGeek is a second event source used only by offline training scripts. No server code reads it.
• TheSportsDB supplies the game schedules those same offline scripts read. No server code reads it either.
• Venmo, Cash App and Zelle are opened as links from your phone. There is no integration and no account. Flock builds a web address and your phone opens it. No money and no payment detail moves through Flock.
• Codemagic builds the iOS app, GitHub Actions scans our code for leaked secrets, and the development tools we write Flock with never touch the product. None of them receives user data.

The people around you

Other members of a flock see what you share inside it: your messages, your RSVP, your vote, your reliability score, and your live location while you have it turned on. The person you are in a direct message with sees what you send them. Your friends see your availability status while it is set. When you press SOS, your trusted contacts receive an email, and people who, like you, have accepted a confirmed plan starting within twelve hours of the alert get an alert in the app, unless they are banned or one of you has blocked the other. Both carry your location when your phone can find one. A venue owner sees the reviews written about their venue, including yours.

Everyone else

We may disclose information to comply with a valid legal process, to protect people from imminent harm, to report apparent child sexual abuse material as the law requires, or in connection with a merger or sale of the business, in which case we will tell you before your information becomes subject to a different policy.

We do not sell personal information, and we do not share it with anyone for advertising.

Analytics, error reports, and email

Product analytics, with PostHog

We use PostHog to understand how Flock is used: pages viewed, and a short list of events we write by hand, such as signing up, logging in, creating a flock, sharing an invite link, and submitting a crowd report. Events are tied to your account number, never to your name or your email, and only signed-in people get a profile at all. Like any web request, the one that carries an event also carries your IP address to PostHog's servers.

None of this happens until you agree to it. Before you answer, and after you decline, PostHog is never started, nothing is written to your device for it, and no event is sent. If you agreed and then change your mind, declining also clears the identifier PostHog stored.

The youngest person allowed on Flock is 13, so the settings are written to collect as little as they can, in code rather than in a dashboard where a toggle could widen them later:

• Automatic capture of clicks and typing is switched off, so no message text, budget amount or form content reaches PostHog.
• Session replay is off. Nothing records your screen.
• Heatmaps, dead-click capture, error autocapture and in-app surveys are all off.
• A browser that sends a Do Not Track signal is not tracked.
• Advertising click identifiers are masked, and invite tokens and coordinates are scrubbed out of every property before an event leaves your device.
• We ask PostHog not to derive a city or region from your IP address.
• PostHog keeps its identifier in your device's local storage rather than in a cookie.

Birdie has one extra measurement. Every call to the model records how many tokens it used and how long it took, against your account number. The words are deliberately left out: PostHog is where we measure cost and speed, not where conversations go.

Crash and error reporting, with Sentry

Sentry is wired into both the app and the server and it is not switched on. With no connection string configured, the code never starts it and the software is not even downloaded to your device, so no crash report is being sent anywhere today.

If we turn it on, this is what it will do. Sentry will receive unhandled errors and a sample of performance traces: the error, where in our code it happened, the page or request it happened on, and the recent steps that led to it. Before any of that leaves your device, invite tokens and anything shaped like a coordinate are replaced with the word "redacted", in the address, in the referrer, in breadcrumbs, in the trace name, and in the individual spans. We do not attach your name or your email to a Sentry event. We will update the effective date on this page when it is switched on.

Email, and how to stop it

Flock sends two kinds of email. Transactional email keeps your account working: the verification link at sign-up, a password reset you asked for, and SOS alerts to your trusted contacts. Those cannot be turned off while your account is active, because turning them off would break the account.

Everything else is optional and every message carries an unsubscribe link that works without signing in. The waitlist confirmation and the Monday venue digest both do, and the two links work differently because the lists are different. Unsubscribing from the waitlist writes your address to a do-not-mail list. Turning off the Monday digest switches off a setting on your venue account instead, so it stops that one email and writes nothing about your address. The digest is off by default and only sends if a venue owner switches weekly reports on. An address that hard-bounces or is reported as spam is added to the do-not-mail list automatically.

The do-not-mail list is checked inside the one function every outgoing message in Flock passes through, rather than in each sender, so there is nothing to forget. One honest limit: if that check cannot reach our database it lets the message go rather than holding it. We would rather send a message we should not have than swallow a password reset or an emergency alert because of a database blip.

Two deliberate exceptions. Unsubscribing from a list does not stop a password reset or an SOS alert, because those are not lists you are on. And an SOS alert is sent even to an address that has hard-bounced or reported us as spam. A bounce says a message failed, not that the person refuses to hear from you, and a complaint about a marketing email is not a refusal of an emergency from the person who named that contact. Because nothing on our side stops that send any more, the Safety screen marks a trusted contact whose address has been failing, so you can fix the address rather than find out later.

How long we keep it

• Account data: until you delete your account.
• Messages, flocks, calendar entries, bill splits, votes and budgets: retained while your account exists; deleted with your account. What that takes with it is described in Deleting your account.
• Crowd reports you file: kept while your account exists and deleted with it. A model that has already been trained on a report does not forget it, and the training set itself carries no account numbers.
• Predictions we served you: 180 days, then deleted automatically.
• Availability status: expires at the time you set. You can clear it yourself.
• Invite links: expire 14 days after they are created, or a week after the plan, whichever is later. A link made today for a plan two months out therefore lives about ten weeks. An invite link is a bearer credential: anyone holding it can see the plan and who is on it, by first name, and can answer, vote and share a budget amount as a guest. Reading the flock's chat or seeing live location takes joining, which needs a signed-in Flock account with a confirmed email. So the expiry is the only thing that retires a link on its own. If a link gets somewhere it should not, the person who created the plan can ask us to kill it.
• Guest RSVPs: the display name, votes and budget amount a guest leaves on an invite link are kept with that plan, and deleted when the plan is deleted.
• Password reset records: the record of a reset request, which holds the requesting IP address and a one-way hash of the email, is deleted after 7 days. The record of an issued reset link, which holds your account number, the address it was mailed to and the requesting IP address, is deleted 7 days after it is spent or expires, and immediately with your account.
• Stories: there is no way to post or see a story anywhere in the Flock app, so using Flock does not create one. Our server does support them: a story there stops being visible to everyone 24 hours after it is posted, and the row is then removed by a cleanup that runs at most once an hour and takes stories that expired more than 24 hours ago. A story that has been reported is held until the report is closed.
• Push notification tokens: deleted when you sign out on that device or delete your account.
• Do-not-mail entries: kept for as long as the address should not be mailed. Removing it is what would let mail resume, so it has no expiry.
• Reports and moderation records: kept after an account is deleted so our moderation history stays intact, but with the deleted account unlinked from them.
• Banned accounts: if an account is banned and its owner then deletes it, we keep a one-way hashed code of its email, phone number, and Apple or Google sign-in ID for 12 months. This stops a banned person from signing straight back up. The code can't be turned back into the original email or number, contains no name or content, and expires on its own after 12 months.
• Deleted accounts: when any account is deleted, we keep a one-way hashed code of the email address it confirmed and of its Apple or Google sign-in ID for 12 months. It is used for one thing only: a new account on the same email or sign-in ID does not get a second first week without the free-tier limits. It holds no name, no phone number and no content, can't be turned back into the email, and expires on its own after 12 months.
• A phone matching code, only while you have "Let friends find me by my phone number" switched on. It is a one-way keyed code of your number, it cannot be turned back into the number, and it is deleted the moment you switch discovery off or delete your account.
• Plan statistics: when a flock ends we keep one row per plan describing how it went: group size, whether a budget was used, the group's ceiling, how many people submitted, whether it was confirmed, how long that took, and where it stalled. It carries no names, no messages, and no individual budget amounts, and once the plan is deleted it is not linked to anyone. We keep these to understand where planning breaks down.
• Venue occupancy readings by owners: kept indefinitely, including retracted and expired ones, because each is a labelled observation the crowd model learns from. They are deleted if the venue account is deleted.
• Venue digest send records: 90 days, then deleted.
• Cached venue photos from Google: 30 days, then re-fetched.
• Sensor readings: kept as venue history. They contain no identifiers. See section 3.
• Waitlist emails: kept until you unsubscribe or ask us to delete the address.
• Server logs: short-term, for security and debugging. Our hosting provider ages them out; we do not archive them.
• Backups: we take database backups, so information you deleted can still sit in a backup until that backup is deleted. Our written rule is that no backup is kept longer than 90 days, with one exception: an occasional archive kept so the crowd-model training data is never lost. Until we can export that data on its own, that archive is a copy of the whole database, which means it can still hold your information after you delete your account.

Deleting your account

You can delete your account from inside the app (You → scroll to the bottom → Delete account) or from our account deletion page. It is a real delete, not a deactivation, and it cannot be undone. To protect your account, deleting it asks you to confirm your password, or to sign in again if you use Apple or Google.

What is erased

• Your account row and everything hanging off it: email, password hash, phone, year of birth (or the full date of birth on an older account), display name, avatar, bio, interests, payment handles, and your settings.
• Every message you sent in a flock chat, and your direct messages. A direct message belongs to both people, so deleting your account removes your direct message threads from the other person's app as well, along with anything pinned or voted on inside them.
• Every flock you created, including its chat, RSVPs and votes, for everybody who was in it. Flocks you only joined survive; your membership in them does not.
• Your crowd reports, your check-ins, your calendar entries, your availability status, your budget submissions, your bill split shares, your trusted contacts, your SOS alert records, your emoji reactions, your friendships, your blocks, your push tokens, your email verification records, and the record of the predictions we served you.
• Your venue profile and everything on it, if you had one, including your occupancy readings, promotions, events and your replies to reviews. The reviews themselves belong to the people who wrote them and stay.
• If you signed in with Apple, the refresh token we held, after we use it to revoke Flock's access to your Apple ID.

What survives, and why

• Moderation records. Reports filed about content and the actions taken on them stay, with your account unlinked from them, so somebody cannot erase an open report about themselves by deleting their account. The de-attribution and the delete happen together: either both worked or neither did.
• A ban tombstone, but only if the account was banned. A one-way hashed code of the email, phone and sign-in ID, for 12 months, so a banned person cannot sign straight back up.
• A first-week code, for any account. A one-way hashed code of the email the account confirmed and its Apple or Google sign-in ID, for 12 months, so that signing up again does not bring back the first week without free-tier limits.
• One row per finished plan, with no names, no messages and no individual amounts, as described under How long we keep it.
• Push notification bookkeeping, which is a delivery ledger that records that a notification was sent, with no message text, kept for thirty days and de-attributed the same way a report is. While you have an account, a notification held for quiet hours keeps its text on our server until it is delivered or a day past its expiry, and a device's push token is dropped after 270 days of silence.
• Sensor readings, which never contained anything belonging to you. See section 3.
• Your address on the do-not-mail list, if it is on it. That list is keyed on the address itself and has no link to your account, so deleting your account does not remove it, and it has no expiry. It exists so that an address that bounced or reported us as spam is not mailed again, which is a promise to whoever holds that mailbox rather than to the account. You can ask us to take an address off it at social@flockcorp.com.
• Two references, emptied rather than removed. If a plan you did not create had a bill split, that split's record of who paid stops pointing at you rather than being deleted, because it belongs to the plan and the plan is somebody else's. The same is true of an invite link somebody else's flock still holds: it stops saying who made it. Neither carries anything about you once your account is gone.
• Backups, until they age out.
• Anything already learned by the crowd model. A trained model is not a database and cannot have one row removed from it. The training data itself carries no account numbers.

If you would rather have a copy of your data before you delete it, you can get one yourself in the app, under You and then Get a copy of my data. You can save it or copy it out, depending on your device. If you would rather we sent it, ask us at social@flockcorp.com.

Your choices and rights

• Access, correction, export, deletion: you can export your data yourself in the app, under You (the last tab) and then Get a copy of my data, and it asks for your password first so that somebody holding your phone cannot lift it. For access or correction, or for the four things named below that the file leaves out, email social@flockcorp.com. An export is a machine-readable copy of your account, your settings, your plans and calendar entries, the messages you sent, your votes, budgets, reactions, reviews, crowd reports, check-ins, bill-split shares, SOS records, friends, reports you filed, your trusted contacts, and your reliability score. Four things are not in that file today and we would rather say so than let you assume otherwise: the record of which crowd predictions we showed you, the list of accounts you have blocked, your registered push notification tokens, and your venue profile if you run a venue. Ask and we will send those too. The file itself also lists what it leaves out and why. You can delete your account yourself in the app (You → Delete account) or from our account deletion page. To protect your account, deleting it asks you to confirm your password, or to sign in again if you use Apple or Google.
• Location: Flock asks before it reads your location and never reads it in the background. You can turn the permission off for Flock in your device settings at any time. The map then opens on a default area and venue search asks you where to look.
• Live location sharing: stop at any time from within the flock or the conversation you started it in.
• Push notifications: Flock asks before it sends any. To stop them, turn notifications off for Flock in your device settings. Signing out also deletes that device's push token from our servers.
• Photos and contacts: both are asked for at the moment you use them, and both can be withdrawn in your device settings. Phone numbers you matched were never stored. Turning off "Let friends find me by my phone number" erases the code we matched you against.
• Email: we don't send marketing email. Optional email, which today means the waitlist confirmation and the Monday venue digest, carries an unsubscribe link in every message and needs no sign-in. Transactional email cannot be turned off while your account is active.
• Blocking and reporting: you can block anyone and report any message, profile, review or guest from inside the app. Our Community Guidelines say where every one of those controls is.
• Complaints: if you think we have handled your information badly, tell us first at social@flockcorp.com. If you are in the EEA or the UK you can also complain to your national data protection authority.

If you are in the EEA or the UK

Flock Social LLC is the controller for the processing described here, and Our legal bases says which basis covers what. You have the following rights, and you exercise all of them the same way, by writing to social@flockcorp.com:

• Access. A copy of the personal data we hold about you, and the information in this policy about how it is used.
• Rectification. Corrections to anything inaccurate. Most of it you can edit yourself in the app.
• Erasure. Deletion, which you can also do yourself. Deleting your account says exactly what goes and what does not.
• Restriction. Ask us to stop using your data while a dispute about it is settled.
• Objection. Object to processing we base on legitimate interests. Say what you object to and we will either stop or explain why we believe our grounds override yours.
• Portability. Your data in a structured, machine-readable form, for the parts you gave us and the parts we process by consent or under our agreement with you.
• Withdraw consent. Location, notifications, photo access, contacts, and the waitlist. Withdrawing does not undo processing that already happened.
• Complain to your supervisory authority.

We answer within one month. We will not charge you and we will not make the service worse for asking. If we cannot identify you from what you send us, we will ask for enough to be sure we are not handing your data to somebody else.

We do not make decisions about you by automated means that produce legal effects or anything similarly significant. The crowd model predicts how busy a building is; it does not decide anything about a person.

If you are in California

Under the California Consumer Privacy Act, as amended by the CPRA, these are the categories of personal information Flock has collected in the last twelve months, why, and who it goes to. Every one of them is described in more detail earlier in this policy.

• Identifiers: email, display name, optional phone, account number, sign-in identifiers from Apple or Google, IP address, push tokens. Collected to run the service and keep it safe. Shared with our hosting, email, push, analytics and sign-in providers.
• Customer records: password hash, payment handles such as a Venmo username. Collected to run sign-in and bill splitting. Not shared, except the hosting that stores them.
• Protected classifications: year of birth, or a full date of birth on accounts created before 15 September 2026, which yields age. Collected only to enforce the minimum age. An age bracket, never the year or the date, is sent to Google for Birdie.
• Commercial information: venues you voted on, checked into, reviewed or reported on, bill splits, and subscription receipts if you ever buy one. Collected to run the product.
• Internet activity: pages viewed and the short list of hand-written events described under Analytics, error reports, and email. Shared with PostHog.
• Geolocation: precise location while you are using the app, for the map, venue search, weather, events and SOS. Relayed, not stored, except for the coordinates in an SOS record. A rounded position goes to Google for Birdie.
• Audio, electronic, visual information: photos you upload, with their hidden camera data removed, and the messages you write. Photos are screened by Google Cloud Vision.
• Inferences: your reliability score, and the crowd predictions we compute for venues.

Sensitive personal information, in the CPRA's sense, means your precise geolocation and your account credentials. We use them only to deliver the features you asked for and to secure your account, which is a use the law does not require us to offer a limit on. We do not use or disclose sensitive personal information for any other purpose, and we do not sell or share it.

We have not sold personal information, and we have not shared it for cross-context behavioural advertising. We do not have an advertising business, we run no advertising software, and there is no "Do Not Sell or Share My Personal Information" link on Flock because there is nothing for it to switch off.

You have the right to know what we collect and why, to get a copy, to correct it, to delete it, and not to be discriminated against for asking. Email social@flockcorp.com and say which one you want. An authorised agent may ask on your behalf with written permission we can verify. We verify a request by checking that it comes from the address on the account, or by asking you to confirm from inside the app.

Children

Flock is for people 13 and older. Sign-up asks for a year of birth and our server works the age out from it rather than trusting the app, so an under-13 account is refused rather than merely discouraged. We do not knowingly collect personal information from children under 13. If you believe a child under 13 has created an account, write to social@flockcorp.com and we will delete it.

Several countries in the EEA set the age at which a young person can consent to an online service above 13, most often at 16. Flock has no way to collect and verify a parent's consent. So if you are between 13 and the age of digital consent where you live, you need your parent or guardian's permission to use Flock, and by using it you are telling us you have it. A parent or guardian who wants an account closed can write to social@flockcorp.com and we will close it.

Flock has zero tolerance for child sexual abuse and exploitation. Our Community Guidelines describe what we do about it, including reporting apparent material to the National Center for Missing and Exploited Children.

We do not build advertising profiles of anyone, so we do not build them of minors either. The analytics settings under Analytics, error reports, and email were written with the 13-year-old in mind.

Security

These are the protections that are actually in place, not a list of aspirations:

• Passwords are hashed with bcrypt. We never see or store the password itself.
• Every connection is HTTPS, and the browser is told to keep it that way.
• Sessions are signed tokens with a fixed algorithm and a version stamp, so signing out everywhere really does invalidate the old ones.
• The most destructive actions, deleting your account and exporting your data, need proof it is really you: your password again, or a fresh sign-in. Wrong guesses are counted and locked out.
• Every database query is parameterised, so a message cannot become a command.
• Rate limits sit on every route people use, with tighter ones on sign-in, on the assistant, on the venue advisor, and on anything unauthenticated. Two routes are exempt and both are machine-to-machine: the notices our email provider and our subscription provider send us. Neither is reachable without the shared secret it is checked against, and rate limiting them would mean discarding a delivery notice we asked for.
• Security headers are set by Helmet, including a content security policy.
• Text and images are screened before they are stored, and an image that cannot be screened is refused rather than let through.
• Uploaded images have their embedded metadata removed before storage.
• Notices from our email provider carry a signature over the exact bytes they sent, and we verify it before reading a word of the message. Our subscription provider does not sign anything; it presents a shared secret in a header, which we compare in constant time. Both are refused outright if the secret on our side is missing or too short to be one.
• Every push to our code is scanned for leaked secrets automatically.
• We take database backups, and we have a tool that restores one into a throwaway database and checks it, because an untested backup is a guess. Being straight about it: running that tool is a manual step today. Making a backup does not run it.

No system is perfectly secure. If you find a problem, write to social@flockcorp.com and we will take it seriously.

If something goes wrong

If personal information is exposed by a breach, we will investigate it, fix what caused it, and tell the people affected without undue delay, describing what happened, what was involved, and what we are doing about it. Where the law sets a deadline, we will meet it: for people in the EEA or the UK that means notifying the relevant supervisory authority within 72 hours of becoming aware of a reportable breach, and telling you directly when the risk to you is high. We will not wait for certainty about every detail before telling you something happened.

International transfers

Our servers are in the United States, and the companies listed under Who we share with are United States companies or process there. If you use Flock from outside the United States, your information is transferred to and processed in the United States, which may not give it the same legal protection as your own country.

We want to be straight about the mechanism, including about what we do not know. Flock has not separately negotiated a transfer agreement with any of the companies listed above. Several of them apply their own data processing terms, including Standard Contractual Clauses, to every account by default, so those may well cover some of these transfers without our having signed anything bespoke. We have not audited each vendor's terms to tell you which, and we will not claim a protection we have not checked. For people in the EEA or the UK, the transfer happens because it is necessary to provide the service you asked us for, and because you agree to it by using Flock. If we put a specific agreement in place, this section changes with it.

What Flock does not do

A privacy policy that only lists what a company takes is half a document. Here is the other half. None of the following happens, anywhere in Flock, today:

• We do not sell personal information, and we do not share it for advertising.
• We do not run ads, and there is no advertising software in the app or on the site.
• We do not track you across other apps or websites. There is no advertising cookie, no pixel, and no data broker.
• We do not read your location in the background, ever. Only while Flock is open and only when you have allowed it.
• We do not keep a location history. Live location sharing is relayed and never written down. The single exception is the SOS record: when you press SOS we store the coordinates that went out, so there is a record of what happened, and it is deleted with your account.
• We do not upload or store your address book. The numbers you pick for a friend match are checked and discarded.
• We do not touch card numbers, bank accounts or any payment credential. No money moves through Flock.
• We do not record your screen, your keystrokes, your microphone or your camera. The only time the camera opens is when you ask it to take a photo or scan a code.
• We do not send your flock chat, your direct messages, your budgets, or your exact position to any AI model. What you type to Birdie itself does go to Google, because that is the only way it can answer you, along with the context named under Birdie and Roost.
• We do not use your messages to train the crowd model. It learns from venue observations, and its training data holds no account numbers.
• We do not show any other person your budget amount.
• We do not tell anybody that a crowd report came from you.
• We do not let a venue see who is in the room, only how many.
• We do not collect health data, biometrics, race, religion, politics, or sexual orientation.
• We do not sell venue owners influence over what consumers see, and we do not accept payment to change a busyness number or bury an honest review.

If any of that ever stops being true, it changes on this page before it changes in the product.

Changes to this policy

We may update this policy. We will post the new effective date at the top and, for material changes, give in-app notice before the change takes effect. If a change means we need your consent for something, we will ask.

Contact

Questions, requests, or concerns? A human reads this inbox:

social@flockcorp.com