Privacy Policy

Account information

Signing up takes an email address, or Sign in with Apple. That is the whole form — we ask for nothing else at the door. The app asks you to sign in when you open it (since the August 2026 update; earlier versions allowed signed-out browsing), and everything you do — browsing, ordering, following, reviewing — happens on your account. At sign-in you also tell us whether you're here as a customer or as a food-truck vendor, which only decides which setup flow you see next.

Everything else we ask for, we ask for at the moment it is actually useful:

• A display name — at your first order, because it goes on the order the vendor calls out. You can change it any time in Account settings.
• A phone number, optional — offered at your first order so the truck can reach you if something goes wrong with that order. You can skip it, and skipping it changes nothing about the order. It is shown only to the vendor you ordered from, and only while that order is open or inside the seven-day refund window. You can add, change or clear it any time in Account settings.
• A profile photo, optional — if you choose to add one. It appears next to your reviews and comments, like your display name does. Without one you get a circle with your initial, which is a completely normal state, and removing a photo is one tap.

We never send you text messages. Not marketing, not order updates. Your phone number exists so a vendor can call you about a live order — order updates arrive as push notifications instead.

We do not ask for your home address or your date of birth. Every order on YumScout is pickup, so there is nothing to deliver to, and we sell nothing that is age-restricted. There is no field for either one anywhere in the app.

Location

Location works very differently for customers and vendors, on purpose:

• Customers: with your permission, we use your device's precise location while you are using the appto center the map and show vendors near you. We never track customers in the background, and your location is never shown to vendors or other users. To power "a vendor you follow just went live near you" notifications, we store only a coarse (roughly 1 km) center point of the last area you looked at — not your precise position.
• Vendors: broadcasting your location is the product. When you go live, your truck or cart's position is published on the public map — that is the point, and you control it with the Go Live and End Shift buttons. Background location is used only if you turn on On-the-Move mode, so your pin can follow your truck while you drive; ending your shift stops it. The raw GPS trail from a live session is kept for 48 hours for debugging and then automatically deleted. The map only ever shows your latest position.

Orders and payments

When you place an order we keep the order details: the items, prices, tip, pickup code, order status history, and any note you add. Payments are processed by Stripe. Your card number goes directly to Stripe and never touches our servers — we never see or store full card numbers. Stripe handles card data under its own privacy policy.

Vendor business information

If you apply to sell on YumScout, we collect your application answers (food type, city, how you sell, photos, social links) and any permit or license documents you choose to upload. Uploaded documents are stored privately and are visible only to our review team. To receive payouts, vendors onboard with Stripe Connect — Stripe collects identity and bank details directly for its "know your customer" checks; we do not store them.

Content you post

Reviews, star ratings, review photos, comments, and vendor replies are public — they appear on vendor profiles along with your display name and, if you set one, your profile photo. A profile photo is public content in the same way: treat it like anything else you post. Don't post anything you wouldn't want public.

Your display name and profile picture are public on their own, not only where you posted something. They sit in a public directory of accounts that anyone can read — other customers, vendors, and people who are not signed in at all. That is what lets your name show up next to a review, a comment or in a vendor's follower list without the app having to sign anyone in first. Three things are worth saying plainly about it. First, the directory itself is onlythose two fields plus the account's internal id. Your email address, your phone number, your order history and the rough map area you last looked at are not in it — nobody reads them from the directory, signed in or not. That is a statement about the directory, and it is not the same as saying nobody else can ever see those things, so here is the whole of it: your email address and the map area are readable by you and by our admins, and by nobody else; your phone number, if you chose to give one, is additionally released to the vendor on an order that is still open, or that you placed within the last 7 days — the refund window — so they can call you about that order, and it stops being released once that passes; your order history is readable by you, and each individual order is also readable by the vendor who cooked it, because it is their sale and their financial record. Our admins can reach all of it — that is what makes handling a report, a refund dispute or a legal request possible — and when an admin acts on something, the record of who acted is kept. We are not going to claim more than that: we do not currently keep a log of every time an admin merely looks, and we would rather tell you so than imply a supervision we have not built. Second, it is a directory, which means someone determined enough could read down the whole list rather than looking up one person — the same as any app where profiles are public. Third, if you would rather not be in it under your real name, your display name is yours to change at any time.

What deleting your account does to the directory entry, exactly. Your display name and profile picture are erased from it, and the picture file is deleted, so nothing that names or shows you is left there. Whether the underlying row goes too depends on one thing: whether you run a truck. If you do not, the row is deleted outright and the entry is gone. If you do, we keep an emptied row — the internal id and nothing else, no name, no photo — because your truck's past orders, payouts and tax records point at it, and deleting it would break the vendor's own financial history. Nobody can learn anything about you from an id with no fields attached, but we would rather tell you it is there than claim the entry vanishes when it does not.

If you run a truck, your account is publicly linked to that truck. When a vendor reviews another truck we label the review “· Verified food truck”, because a review written by a competitor is not the same as a review written by a customer and you deserve to know which one you are reading. The mechanism behind that label answers the question “which approved truck does this account own?”, and it answers it for anyone, including someone who is not signed in — not only on a review page. Combined with the public directory above, that means the name and photo on your account can be matched to your truck's name in bulk, by someone who never opens the app. We think a truck owner's identity being public is right — you are a business, trading under a name, taking money from strangers — but it is not obvious from using the app, so we are saying it rather than letting you find out. Customers who do not run a truck are not in this at all: the lookup returns nothing for them.

Following a vendor is public too, by name. Every vendor profile has a follower count, and tapping it opens the list of who those followers are — your display name, your profile picture and the date you followed. That list is readable by anyone: other customers, the vendor, and people who are not signed in at all. It is the same as following a public account on Instagram or X, and it is built that way on purpose so a truck can show it has a following — but it is a named, public list, so we are not going to let you find that out by accident. Unfollowing removes you from it immediately. Deleting your account removes every follow you ever made.

Automated screening of what you post

Before a photo, video, review, comment, caption, profile picture or order message goes live, it is checked automatically by a content classifier — software that looks for sexual content, graphic violence, hate, self-harm and illegal imagery. That means the content itself (the image, or the text you wrote) is sent to our screening providers, Sightengine and Google Cloud Vision, which return a classification.

What they receive differs between text and images, and the difference is worth stating rather than smoothing over. For text, we send the words and nothing else — no name, no account, no location. For an image or video, we do not upload the file; we send a link to it in our storage, and the classifier fetches it. That link contains the account ID of whoever uploaded the file, because that is how our storage is organised and how we verify you own what you are asking us to screen. So the screening providers do receive an account identifier alongside the picture. It is a random ID that means nothing to them — they cannot look up who it belongs to, they get no name, email, phone or location, and their side of the arrangement is to classify the content and not to profile anyone. But “the content and nothing else” would not be true, so we do not say it.

We do this because Apple requires a filter on user content, and because we would rather a machine catch something at 3am than have it sit in front of people until someone reports it. A machine decision is never the last word: content the classifier flags goes to a human review queue, you are told when something of yours is removed, and you can appeal. Nothing here is used to profile you or to advertise to you.

We keep the screening record, including for things that were never published. Each check writes a row: your account ID, which surface it came from, the verdict, the category scores, and up to the first 512 characters of the text itself (or, for an image, a link to it). If the classifier refuses something, that row is written and kept even though nobody but you ever saw what you typed — because a refusal is what a strike, a warning and an appeal are built on, and a safety record you delete on request is not a safety record. Only our admins can read these rows; no vendor and no other customer can. They are not deleted on a schedule.

What happens to them when you delete your account depends on whether you run a truck, and we would rather tell you that than give you a tidy sentence that is only half true. If you are a customer, deleting your account deletes these rows too, along with any strikes, standing and appeals attached to you — the whole account goes, and they go with it. If you own a vendor, the account record itself has to be kept (a truck has orders, payouts and a tax trail behind it), and the screening rows, strikes and appeals are kept with it. Two things are kept in both cases, and they are the ones that exist precisely so that deleting an account is not a way to start over with a clean slate: anything held under a legal preservation order, and a set of one-way fingerprints — a scrambled form of the email address, device and payment method behind an account we had to ban. Those fingerprints cannot be turned back into your details and are never used for anything but refusing a re-registration.

Notifications and device data

If you enable push notifications, we store a push token for your device along with your notification preferences (which types you want, your go-live radius, quiet hours). We use it to send the notifications you asked for — vendor go-live alerts, order status updates, review replies — and nothing else.

To avoid sending you the same thing twice we keep a small delivery record: for a paid vendor promotion, one row per vendor per account with the time we last sent you one, which is how the once-a-day and once-per-vendor-per-24-hours limits are enforced. It records that a notification was sent to you — not whether you opened it, and not anything you did afterwards. Only our own servers can read it, and it is deleted with your account.

How you use the app: view counts, and the Feed

Two different things happen here, and they deserve to be described separately rather than rolled into one comfortable sentence.

Live-session counters are just counters. When you tap a vendor's pin on the map or open their profile, we add one to a number on that vendor's current live session. Nothing about you is stored alongside it — it really is a tally, and it is the only thing a vendor sees about map traffic.

Vendor posts are different: we keep a per-person record. For posts in the Feed — the photos and videos vendors publish — we store one row for each post you interact with, and that row is keyed to you. It records which post, which vendor, which kind of interaction, and when. The kinds are: the post scrolled into view and stayed there (an “impression” — at least 60% of it on screen for at least a second), a like, a comment, a tap through to the vendor's profile, a follow that started from the post, and an order placed with that vendor shortly after tapping through from their post. At most one row per post, per kind, per day, so scrolling past the same post ten times is still one row.

That row carries your account ID. On app versions from before the August 2026 sign-in requirement, someone browsing signed-out generated these rows under a random guest ID the device created on first launch and kept until its storage was cleared — not derived from the device, an account, or an IP address, but stable, so guest activity was linkable to itself across sessions. Current versions require sign-in, so new rows are account rows; old guest rows persist as described until the app's storage is cleared.

What it is for, plainly: ordering your Feed. Once you are signed in and have liked, ordered from, or tapped through to at least three posts, we work out which cuisines you lean toward from those actions — weighted so an order counts for more than a like, and decayed so a taste from two months ago fades — and posts from vendors in those cuisines are ranked higher for you. Newness still comes first: a post from today always outranks a post from last week, and this only re-orders posts within the same day. Separately, a post that a lot of people interact with relative to how often it is seen is ranked a little higher for everyone. Your own impressions feed that platform-wide number; they never feed your personal taste profile.

What we do not do with post interactions. We do not show them to vendors — for the posts described above, a vendor sees totals and rates for their own posts and can never see who viewed or tapped. No customer, and no third party, can read these rows at all; only our own servers can. We do not use them for advertising, we do not sell or share them, and we use no third-party advertising trackers. They are not used to decide what you pay. And they live only as long as the post and your account do: delete your account and this history is deleted with it, along with the guest ID if you clear the app's storage.

Two things a vendor CAN see with your name on them. This paragraph used to end “who viewed, tapped or followed”, and the last word was wrong. A vendor can see their follower list by name — so can everybody else, including people who are not signed in (see “Content you post” above) — and a vendor can see who watched their stories, which is described immediately below. Impressions, profile taps and the order-attribution rows are the ones nobody but our servers ever sees, and that part is unchanged.

Stories are different again: the vendor sees your name. When you watch a vendor's story — the 24-hour full-screen posts behind the ring on their profile — we store one row saying which story, which account watched it, and at what time. Watching it again updates the same row rather than adding another. That row does two things. It turns the ring grey so you can see what you have already watched. And it puts you on the story owner's viewer list: the vendor who posted it can open a “who watched this” sheet and see your display name, your profile picture and when you watched, the same way Instagram does. This works exactly like the story features you already know, which is why it is built this way — but it is the one place a vendor is shown WHO looked, by name, so we are not going to leave it to be assumed. Only the vendor who posted the story, you, and our admins can read it; no other customer and no third party can. There is no equivalent for the Feed, and none for the map. Signed-in accounts only — story watching is not recorded for guests, because the row is keyed to a real profile.

Story-view rows are deleted with the story itself, which expires 24 hours after it is posted and is swept away about an hour later — so a watch is normally gone inside about 25 hours. The one exception is a story that has been reported: we keep those (and their rows) while the report is open and for 30 days after, so we can act on it. Deleting your account also deletes your rows.

Opening checkout at a truck writes a row too. When you open checkout at a vendor, we save one row saying that your account has a cart open at that truck, when you opened it and when your app last checked in. It exists so a vendor who pauses or ends their shift can choose to let the people already mid-order finish — the truck sees a number (“3 carts open”), never a name, and no other customer can see it at all. Only you, and our servers, can read your row. There is one row per truck, refreshed rather than added to when you come back — but the rows are not deleted on a schedule, so over time the set of them is a list of the trucks whose checkout you have opened. Deleting your account deletes them.

And two small ones, for completeness. An order's message thread stores a per-person bookmark of how far you have read, so the app can show you what is new. Only you can read your own bookmark — deliberately, because that is what stops it becoming a read receipt the other side could see. And every notification we try to send you leaves a delivery record saying which notification, to which account, and whether it was sent or skipped (and if skipped, why — quiet hours, or you had that notification type switched off). That record is how we can tell “we never sent it” from “we sent it and it did not arrive”; our admins can read it, and no vendor or customer can.

Until August 2026 this section said we build no browsing profiles. That was written about the pin-tap counters and it was left standing when the Feed shipped, which made it wrong. The Feed does use your own past interactions to order what you see. We would rather say so. The same correction applies to story views: this page previously said, without qualification, that a vendor can never see who viewed — true of posts, false of stories, and it had been false since stories shipped in v1.3. That sentence is now scoped to posts and stories are described above.

Crash and error reports

Not in the app you have today. Crash reporting is described here in full because it arrives in the next app update, and we would rather tell you before it starts than after. The version currently on the App Store contains no crash reporter and sends nothing to Sentry. When the update ships, this note comes out and the effective date at the top changes.

When something in the app, on this site, or on our servers breaks, an automatic error report is sent to Sentry so we can fix it. A report carries: the error and where in the code it happened; your app version, OTA update id, device model and OS version, plus device state like free memory, battery, orientation, screen size, timezone and locale — but never how much free storage you have and never when your device last restarted, both of which we strip out before the report leaves your phone; internal IDs for the things involved — an order, a vendor, a post, and your account's random user ID; and a short trail of the last few minutes before the failure — which screens you were on, which network requests ran and whether they succeeded, and messages the app logged to its own console.

That is a description of the categories, not a closed list, and we say so deliberately: a crash report is generated by code we did not all write, and promising an exact enumeration would be a promise we could not keep across an SDK update. What we can promise is the subtraction, because it is enforced by a filter the report passes through before it is sent — the same filter everywhere, running wherever the report is made: on your device for the app, in the browser for the admin screens of this website, and on our servers for everything else. It removes your name, email, phone number, address, your location and any coordinates, order contents and item names, notes, messages, review and caption text, pickup codes, payment details, and every login token, cookie and request header. Those fields are removed by code, not by policy.

What happens when the app crashes hard, and what we gave up to keep the sentence above true: if the app crashes hard — an iOS-level crash, a freeze the system kills, an out-of-memory shutdown — there is no running app left to filter anything, so the crash-reporting SDK would have sent its own record at the next launch without passing through the filter. That record would have carried device state we promise to remove, including how much free storage you have and when your device last restarted. So we turned that off. The app no longer reports hard crashes at all. It costs us real diagnostics — an iOS-level crash inside the map, the video player or the payment sheet now reaches us only if you tell us about it — and we would rather pay that than publish a filter that does not run. Everything the app does report, plus everything from this website and from our servers, passes through the filter described above, with no exception.

One more thing that is true of everyreport and not just the hard crashes: a report is delivered over a network request, so the IP address that request comes from — your device's for the app, your browser's for this website, our server's for the backend — necessarily reaches Sentry as it arrives, whatever the filter removed from the contents. That is a property of sending anything over the internet rather than something we chose to collect. We never put an IP address into a report ourselves, and Sentry's “do not store IP addresses” setting is turned on for our projects, so it is discarded on arrival rather than kept.

The IDs that remain are random and meaningless to Sentry — but we can look them up in our own database, so we treat these reports as linked to you rather than anonymous, and our App Store privacy label says so. If you would rather this page did not exist, so would we — it exists because nobody reports a bug from a food truck line, and an app that cannot tell us it broke stays broken.