Platform · Uber Eats

Uber Eats Data Scraping

Q: Do you collect alcohol pricing?

Listings where licensing permits, with an age_restricted flag and serviceability recorded separately for those lines, because a merchant can serve groceries to an address and not alcohol. We do not attempt age verification or any checkout step — that is an action on a third-party system rather than collection.

Four verticals in one app, across thirty-odd countries, and a price that is usually not the retailer's price.

Uber Eats data scraping covers four distinct verticals in one app: restaurants, grocery, retail and alcohol. The rule that decides whether a dataset is usable is that merchants set their own platform prices, and those frequently sit above the same merchant's in-store price. A platform price is a platform price. It is not the retailer's price, and treating it as one inverts most competitive conclusions.

The most common mistake with delivery-platform data is reading it as retail pricing. On a marketplace it is a different number set by a different party for a different reason.

Get a free sample See sample data

Free pilot on your own Uber Eats list, returned in 24 hours. No card, no trial clock — and you keep the sample data either way.

ubereats.jsonl LIVE FEED

{"merchant_id":"ue-44120","vertical":"grocery", "country":"GB","address_id":"LON-CENTRAL-018", "item_name":"Example pasta 500g", "price":2.85,"currency":"GBP", "price_setter":"merchant", "delivery_fee":2.49,"service_fee":1.20, "in_stock":true, "note":"merchant sets this — it is NOT the retailer shelf price"} {"merchant_id":"ue-44120","vertical":"restaurant", "item_price":11.50, "modifier_groups":[{"name":"Size","is_required":true, "options":[{"label":"Regular","price":2.00}]}], "min_realisable_price":13.50} {"country":"PL", "verticals_observed_country":["restaurant","grocery"], "caution":"retail and alcohol NOT live here — absence is structural, not missing merchants"}

3 of 8,204,110 merchant-item rows · 12 countriesprice_setter = merchant on every record · schema v1.0

Independence and trademarks. Actowiz Solutions is not affiliated with, endorsed by or connected to Uber Eats or its owners. Uber Eats and related marks belong to their respective owners, used here only to name the publicly accessible source this service collects from.

Our Data Powers

B2C Marketplace

amazon

D2C + Marketplace

NYKAA

D2C + Marketplace

Walmart

FMCG Marketplace

udaan

Food Delivery

Uber Eats

Quick Commerce

blinkit

Taxi Aggregator

Uber

E-Commerce

Tmall

Uber Eats at a glance

How we handle Uber Eats specifically

Platform-specific handling, not a generic retail template pointed at a different domain.

Platform: Uber Eats — restaurants, grocery, retail and alcohol
The critical rule: Merchant-set prices, frequently above in-store
Vertical: A dimension on every record. The four behave differently
Country: Vertical availability differs per market. Recorded, not assumed
Granularity: Delivery address, since merchant availability is radius-based
Fees: Delivery, service and small-order fees separate from item price
Alcohol: Present where licensed. Flagged, and never age-verified by us
Refresh: Daily standard; sub-daily where promotional intensity is the question

Platform specifics

What makes Uber Eats different from a retailer feed

These are the reasons a Uber Eats dataset needs its own handling rather than a shared retail schema.

The markup problem, and why it inverts conclusions

On a marketplace, the merchant sets the price shown in the app. For grocery and retail merchants that price is frequently above the same item's shelf price in their own store, because the merchant is covering commission.

A retailer looking expensive on Uber Eats may be perfectly competitive in store.
The markup is not constant — it varies by merchant, category and sometimes by item, so it cannot be corrected for with a flat adjustment.
Comparing an owned-inventory operator like DashMart or Gopuff to a marketplace merchant on headline item price ranks them for reasons unrelated to competitiveness.

We record price_setter as merchant on every record, and we do not infer a markup where we cannot see both sides. Where you also supply the merchant's own-channel price, or where we collect it separately, the difference is an observation you compute rather than a number we assert.

This is the same distinction our DashMart page draws inside DoorDash, and it is the single most useful thing to get right in delivery-platform data.

Four verticals that behave nothing alike

Restaurants, grocery, retail and alcohol share an app and almost no mechanics.

Restaurants — prepared items with modifier groups, where the headline price is rarely the entry price.
Grocery — retail packs needing unit-price parsing, with availability that moves through the day.
Retail — convenience and general merchandise, thinner assortment, slower price movement.
Alcohol — licence-dependent, geographically restricted, and gated at checkout.

vertical is on every record and the verticals are never pooled. A blended basket across restaurant items and grocery packs produces an average of two things nobody buys together.

Vertical availability differs by country

Not every vertical is live in every market. We record which verticals were observed per country rather than assuming a global footprint, so a coverage gap in one market is visible instead of looking like an absence of merchants.

Address-level, and the alcohol boundary

Address, not postcode

Merchant availability is radius-based, so which merchants a shopper sees depends on their exact address. We use a designed address panel, record serviceable as a state distinct from an item being out of stock, and hold the panel fixed so a series stays comparable.

Alcohol

Alcohol appears where licensing permits, with availability varying by jurisdiction in ways the catalogue does not always show. We capture listings, flag age_restricted, and record serviceability for those lines separately — a merchant can serve groceries to an address and not alcohol.

We do not attempt age verification or any checkout step. That is an action on a third-party system rather than collection, and the same boundary applies here as on every other platform.

Scope

What we collect on Uber Eats, and what we do not

The right column matters more than the left. Anyone can list fields; the limits are what tell you whether the dataset will hold up.

✅ What we collect

Item price at address level, with the vertical on every record
price_setter recorded as merchant, since that is who sets it
Modifier groups for restaurant items, with required flags and option prices
Minimum realisable price for restaurant items, on a stated basis
Pack size and unit parsed for grocery, with unit price on a stated basis
Delivery, service and small-order fees as separate fields
Serviceability as a distinct state from out of stock
Verticals observed per country, recorded rather than assumed
age_restricted flag with separate serviceability for those lines

❌ What we do not, and why

A markup inferred where we cannot observe both sides
A blended basket pooling restaurant items and grocery packs
Age verification or any checkout step
Sales, order volumes or merchant revenue
Customer, courier or order data

Core Uber Eats fields

The full dictionary is agreed during scoping. These are the fields specific to this platform.

Field	What it is on this platform
merchant_id / merchant_name / vertical	Who, and which of the four verticals
country / city / address_id	Address panel point and geography
item_id / item_name	As published
price / currency / price_setter	Price, and that the merchant set it
modifier_groups / min_realisable_price	Restaurant items, with the basis stated
pack_size / pack_unit / price_per_unit	Grocery items, parsed
delivery_fee / service_fee / small_order_fee	Each separately
serviceable / in_stock	Two distinct states
age_restricted / age_restricted_serviceable	Flag plus separate serviceability
verticals_observed_country	What was live in this market, per batch
observed_at / daypart	Timestamp and derived daypart

Use cases

What teams do with Uber Eats data

Multi-vertical competitive tracking on one panel

Restaurants, grocery, retail and alcohol on the same address panel with the vertical recorded, so each is analysed on its own terms rather than pooled into an average nobody buys.

Marketplace versus owned-inventory comparison

price_setter on every record, so Uber Eats merchant pricing is compared to DashMart or Gopuff owned pricing with the structural difference visible rather than hidden.

Merchant channel-pricing gap

Platform price alongside the merchant's own-channel price where you supply or we collect it, so the markup is an observation rather than an assumption.

Global vertical rollout tracking

Verticals observed per country over time, showing where grocery, retail or alcohol have gone live before any announcement.

The 24-hour sample — run on your sources, not ours

Send us a Uber Eats item or category list. We run real collection against it and return the output within 24 hours, with the platform-specific fields populated so you can check them yourself rather than take our word for it.

Real extraction from your actual sources
Returned within 24 hours
Coverage and QA note included
You keep the data either way
No card, no trial clock
Named engineer on the call

Get my free sample Book a 20-min scoping call Reply within one business day. Reference calls available under NDA.

How we engage

Three ways to engage us

Same collection pipeline and QA underneath. The difference is who holds the schedule and how the data reaches you.

Managed service (most common)

We own the collection, the QA and the delivery. You receive clean data on a schedule and never touch a scraper.

Dedicated engineer assigned to your account
Site changes fixed by us, not reported to you
Scheduled delivery to your warehouse or S3
Named contact on Slack or email

Best fit: Teams who need the data, not the infrastructure.

API access

The same collection pipeline exposed as an authenticated REST endpoint your systems query directly.

On-demand and scheduled endpoints
Rate limits agreed to your load profile
Sandbox keys for integration testing
Versioned schema with deprecation notice

Best fit: Product and engineering teams building on live data.

One-time or project extraction

A defined pull for a specific question — market sizing, diligence, a pitch, a one-off audit.

Fixed scope agreed in writing upfront
Single delivery with full QA report
Methodology documented for your records
Converts to managed if you want continuity

Best fit: Research, strategy and diligence work with a deadline.

Pricing

Every engagement is quoted individually, because the honest answer depends on your scope: how many sources, how many records, how often, and how the data reaches you. We scope it with you, run a free pilot on your own sources, and then quote a fixed monthly figure — no per-request metering and no overage billing when volumes move. Request a quote and you will have a number after one call.

Uber Eats is usually collected alongside its competitors

Almost nobody buys a single platform in isolation. Uber Eats data becomes useful when it sits next to the competitor set on one schema, refreshed on one schedule, so a price index or availability comparison is genuinely like-for-like.

That is what food & restaurant data covers, and a Uber Eats-only engagement can be expanded into it without rebuilding. If you already know you need several platforms, start there instead — it is the same pipeline and usually the better scoping conversation.

FAQ

Uber Eats data scraping: frequently asked questions

Platform-specific questions, including what cannot be collected here.

No, and this is the most important thing on the page. Merchants set their own platform prices, and for grocery and retail those frequently sit above the same item's shelf price because the merchant is covering commission.

A retailer looking expensive on the platform may be perfectly competitive in store. We record price_setter as merchant so nothing downstream mistakes one for the other.

Only where both sides are observable. Where you supply the merchant's own-channel prices, or where we collect them separately, the difference is a calculation you make from two observations.

We will not infer a markup percentage from one side. The markup varies by merchant, category and item, so an inferred figure would be a model presented as a measurement.

Because they share an app and almost no mechanics. Restaurant items have modifier groups where the headline price is rarely the entry price; grocery needs unit-price parsing; retail moves slowly; alcohol is licence-dependent and checkout-gated.

A blended basket across them produces an average of things nobody buys together.

Because merchant availability is radius-based. Which merchants a shopper sees depends on their exact address, and two addresses in one postcode can see different merchant sets.

We use a designed address panel and hold it fixed, so a series measures the market rather than a moving observation set.

Listings where licensing permits, with an age_restricted flag and serviceability recorded separately for those lines, because a merchant can serve groceries to an address and not alcohol.

We do not attempt age verification or any checkout step — that is an action on a third-party system rather than collection.

We quote individually. Drivers are country count, address panel size, merchant or SKU breadth and refresh frequency. Vertical count matters too, since restaurant modifier depth multiplies records well beyond item counts.

One scoping call, a free pilot within 24 hours, then a fixed monthly quote. Request a quote.

See real Uber Eats data before you commit to anything

Send us an item or category list. We return the output within 24 hours with the platform-specific fields populated.

Get a free sample Talk to an engineer

Free pilot, no card, no obligation. If we cannot collect a field you need on this platform, the sample shows you that too.

Hear It Directly from Our Clients

Watch how businesses like yours are using Actowiz data to drive growth.

▶

1 min

★★★★★

"Actowiz Solutions offered exceptional support with transparency and guidance throughout. Anna and Saga made the process easy for a non-technical user like me. Great service, fair pricing!"

Thomas Galido

Co-Founder / Head of Product at Upright Data Inc.

▶

2 min

★★★★★

"Actowiz delivered impeccable results for our company. Their team ensured data accuracy and on-time delivery. The competitive intelligence completely transformed our pricing strategy."

Iulen Ibanez

CEO / Datacy.es

▶

1:30

★★★★★

"What impressed me most was the speed — we went from requirement to production data in under 48 hours. The API integration was seamless and the support team is always responsive."

Febbin Chacko

-Fin, Small Business Owner