Platform · Grubhub

Grubhub Data Scraping

Consumer, campus and corporate ordering sit on one platform at different prices. Channel is a field, not a footnote.

Grubhub data scraping collects restaurant menus, item pricing, fees and availability across US markets. What distinguishes it from the other large US platforms: alongside the consumer marketplace it runs campus dining and corporate ordering channels, and those carry different pricing and different merchant sets. Pooling them produces a price series that moves with channel mix.

Every US delivery platform has a consumer marketplace. This one has two more channels underneath it, and most datasets never separate them.

Get a free sample See sample data

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

grubhub.jsonl LIVE FEED

{"platform":"grubhub","channel":"consumer", "merchant_id":"gh-44120","city":"Example city", "item_price":14.99,"price_setter":"merchant", "min_realisable_price":16.99, "delivery_fee":2.99,"service_fee":3.15, "also_on_other_platform":true} {"channel":"campus", "item_price":"null","gated_share_channel":0.72, "caution":"meal-plan pricing behind an institutional login. 72% not visible"} {"student_data":"not_collected", "meal_plan_balance":"not_collected", "note":"a campus channel sits inside an institution and its users are students"}

3 of 3,204,110 merchant-item rows · USchannel on every row · never pooled · schema v1.0

Independence and trademarks. Actowiz Solutions is not affiliated with, endorsed by or connected to Grubhub or its owners. Grubhub 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

Grubhub at a glance

How we handle Grubhub specifically

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

Platform: Grubhub — United States
Consumer: The marketplace, as on any delivery platform
Campus: University dining, with meal-plan pricing
Corporate: Enterprise ordering, with negotiated arrangements
So: channel on every record
Price setter: Merchant on the consumer marketplace
Fees: Delivery, service and small-order, each separate
Refresh: Daily standard; sub-daily where promotional intensity is the question

Platform specifics

Three channels, one platform

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

Campus and corporate are not the consumer marketplace

The consumer marketplace works the way any delivery platform does: merchants list, merchants set prices, the platform takes commission.

The other two channels do not.

Campus dining operates inside university arrangements, frequently with meal-plan credit as the payment mechanism rather than an open price.
Corporate ordering runs on enterprise arrangements, with merchant sets and terms that differ from the consumer side.
Merchant availability differs — some merchants appear on one channel and not another.
Pricing differs where the same merchant appears on more than one.

channel is on every record. This is the surface separation argument applied to a platform that runs its surfaces as business lines rather than as storefronts.

What we can and cannot see

Consumer marketplace listings are public. Campus and corporate pricing behind an institutional login is gated, and we do not create accounts or use client credentials. Where it is publicly visible we collect it; where it is not, gated_share_channel is reported.

Standard marketplace mechanics, applied

On the consumer side everything our Uber Eats page sets out applies, and we apply it rather than restating it at length.

The merchant sets the price, frequently above their own dine-in price to cover commission. We do not infer the markup from one side.
Modifier groups make the headline item price not the entry price. Required selections mean min_realisable_price is the comparable figure.
Fees are separate fields — delivery, service, small order — never folded into item prices.
Availability is address-level, since merchant reach is radius-based.

Where it sits competitively

This is the third of the three large US platforms by share. For a national US delivery panel all three are usually needed, because merchant overlap is high in dense metros and falls outside them — the coverage argument our regional aggregator page makes.

We record also_on_other_platform where you collect more than one, so the overlap is measured rather than assumed.

What we do not collect

Campus or corporate pricing behind an institutional login. No accounts created, no client credentials used — the boundary our access page sets out.
Meal-plan balances, student or employee data. Never, in any form.
Order volumes, merchant revenue or platform take rate. Not published.
Courier, customer or reviewer identity. Review counts and ratings only.

On campus data specifically

This needs stating plainly. A campus dining channel sits inside an institution and its users are students. Nothing identifying an individual is collected, and where a campus listing carries any personal context we do not collect that text — the same care our SpareRoom page applies for the same reason.

What we collect on that channel is the commercial content: merchant, menu, price where publicly visible, and availability.

Scope

What we collect on Grubhub, 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

channel on every record — consumer, campus or corporate
gated_share_channel reported where institutional pricing is not public
price_setter recorded as merchant on the consumer marketplace
Modifier groups with minimum realisable price
Delivery, service and small-order fees as separate fields
Address-level availability, since merchant reach is radius-based
also_on_other_platform where more than one platform is in scope
Review counts and ratings, without reviewer identity
Merchant open state distinct from an item being unavailable

❌ What we do not, and why

Channels pooled into one price series
An institutional account created or client credentials used
A markup inferred from one platform
Meal-plan balances, student or employee data
Order volumes, merchant revenue or platform take rate

Core Grubhub fields

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

Field	What it is on this platform
platform / channel	consumer, campus or corporate
merchant_id / merchant_name / city	A commercial entity, and where
item_id / item_name	As listed
item_price / price_setter	Price, and that the merchant set it
modifier_groups / min_realisable_price / price_basis	The number a customer can pay
delivery_fee / service_fee / small_order_fee	Each separately
gated_share_channel	Where institutional pricing is not public
address_id / serviceable	Availability is address-level
also_on_other_platform	Where more than one platform is in scope
review_count / rating	Values only
observed_at / daypart	Timestamp and derived daypart

Use cases

What teams do with Grubhub data

Three-platform US delivery panel

This platform alongside the other two large US operators, since merchant overlap is high in dense metros and falls outside them — so a two-platform panel thins where it matters.

Channel-separated pricing

Channel on every record, so consumer marketplace pricing is not blended with campus or corporate arrangements that price on a different basis.

Menu pricing at realisable level

Modifier groups with minimum realisable price, so merchants listing identically are not treated as equivalent.

Merchant overlap measurement

Presence on other platforms recorded where they are in scope, so the value of adding a platform is measured rather than assumed.

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

Send us a Grubhub 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.

Grubhub is usually collected alongside its competitors

Almost nobody buys a single platform in isolation. Grubhub 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 Grubhub-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

Grubhub data scraping: frequently asked questions

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

Because campus dining and corporate ordering do not work like the consumer marketplace. Campus frequently uses meal-plan credit rather than an open price, and corporate runs on enterprise arrangements with different merchant sets and terms.

Where the same merchant appears on more than one channel the pricing differs. Pooling them produces a series that moves with channel mix.

Where it is publicly visible, yes. Where it sits behind an institutional login, no — we do not create accounts or use client credentials in any market.

We report gated_share_channel so an analysis states what it could not see.

Usually, for a national panel. Merchant overlap between the large US platforms is high in dense metros and falls outside them, so a two-platform panel thins in exactly the markets where coverage questions arise.

We record presence on other platforms where they are in scope, so you can measure the overlap rather than assume it.

No. The merchant sets the platform price and it frequently sits above dine-in to cover commission.

We record the price setter and do not infer the markup from one side — that calculation needs both, which is why the chain-direct page exists.

Nothing identifying an individual is collected, in any form. Where a campus listing carries personal context we do not collect that text.

What we collect on that channel is commercial content: merchant, menu, price where publicly visible, and availability.

We quote individually on merchants, address panel size and refresh. Whether campus and corporate channels are in scope affects it, since each adds a separate merchant set.

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

See real Grubhub 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