A Loyalty Program for Uber Eats Customers: How to Get Them Ordering Direct
A busy night on Uber Eats can look exactly like growth: forty orders, a kitchen that never stops, a phone buzzing with new-order chimes until close. What it usually isn't is forty new relationships. A customer who orders from the same restaurant forty times through a delivery marketplace can still be, as far as the restaurant can tell, a stranger — the same stranger as after the first order. That's not bad marketing on the restaurant's part. It's what the marketplace's own API is built to allow.
What Uber Eats' own order data actually contains
It's worth looking at what actually reaches a restaurant when an order comes in, according to Uber Eats' published API documentation — not at what an owner assumes must be in there somewhere. The webhook that fires the moment an order lands carries no customer data at all; it's the order itself, nothing about who placed it. The order-details endpoint a restaurant can call afterward returns a first name, a last initial, and a phone number that's anonymized — it routes through Uber Eats' own system and needs a dial code to reach, not a number that calls the customer directly. There's no email address in that payload at any point. And the one customer identifier the API does expose is documented as unique to that single order: it isn't the value that shows up the next time the same person orders, so there's no field anywhere that lets a restaurant match "this is the same regular as last week," even by accident.
Forty orders, zero contacts
Put those three facts together and the problem stops being vague. A restaurant can serve the same person forty times through Uber Eats and still have no way to reach them once, outside it. Not a text, not a birthday offer, not a "come back, we miss you" — there's no field in the data that would let a restaurant even attempt it. Most owners feel this without being able to name it: the regulars they can spot on a Friday shift don't show up as regulars anywhere on the marketplace's dashboard, because to the marketplace, they aren't a returning customer — they're a returning order.
Why that's the design, not an oversight
None of this is a bug Uber Eats forgot to fix. A marketplace's entire value, to itself, comes from standing between a restaurant and the people who order from it — the day a restaurant can reach that customer directly and skip the marketplace on the next order is the day the marketplace has less reason to be paid for that order. The API is detailed about the order and thin about the person on purpose. It isn't withholding out of carelessness; the restriction is the business model.
What actually gets a customer back
None of that means a restaurant is stuck waiting on an integration that will never exist. It means the contact has to be built by the restaurant itself, at the one moment it still fully controls: when the order leaves the kitchen. A card or a small insert with a QR code, dropped into the bag, sends that customer to a page the restaurant owns — a sign-up for its own loyalty card — and from there, the restaurant has whatever the customer chooses to hand over directly, not whatever an API was willing to expose. That's also the moment a delivery customer becomes someone who might order direct next time, because now there's a way to remind them the restaurant exists outside the app they ordered through.
Why single-use is the part that matters
The detail that decides whether this actually works is single-use. A generic QR code printed once and stuck on the counter, or reused across every bag for a month, has an obvious hole in it: anyone can photograph it, post it, or pass it to a friend, and the restaurant ends up handing out the same reward to people it never served. A code that's good for exactly one redemption doesn't have that problem — it's bounded by how many the restaurant actually printed, not by how far a photo can travel. That's the whole difference between an insert-in-bag code as a gimmick and as something that protects a loyalty stamp program's math.
That's what Ruffus's printable stamp codes are for: single-use QR codes generated in batches, meant to be slipped into delivery bags or online orders so a marketplace customer can scan one, sign up, and collect a stamp — no app for them to install, no integration with the marketplace for the restaurant to build, because none exists to build. It runs on the same tap-and-go mechanics already built for the counter, just applied to a channel that has no counter. What a restaurant does with that contact afterward is its own call — a stamp card, an occasional message, nothing at all — but for the first time, it's a call the restaurant gets to make.
The short version
Uber Eats' API isn't hiding a customer's contact information by accident — it was never built to hand it over, because the marketplace's business depends on staying between the restaurant and the person who ordered. The fix isn't asking harder or waiting for an integration that isn't coming. It's a single-use code in the one place a restaurant already controls — the bag leaving the kitchen — that finally lets that customer opt into a relationship the marketplace was never going to give away.