Platform · iFood

iFood Data Scraping

The dominant platform in a country where regional price differences are wide enough to make a national average meaningless.

iFood data scraping collects restaurant menus, grocery, pharmacy and convenience listings across Brazilian cities. Two things shape every engagement: regional price variation is wide — a national average describes no actual market — and modifier groups carry the real price, so a headline item price ranks restaurants wrongly.

Brazil is one market on a map and several on a price chart. The gap between a São Paulo neighbourhood and a northeastern capital is larger than the gap between many European countries.

Get a free sample See sample data

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

ifood.jsonl LIVE FEED

{"store_id":"if-44120","brand_id":"brand-882", "city":"Sao Paulo","neighbourhood":"Pinheiros", "vertical":"restaurant", "item_name_pt":"Prato executivo", "item_price":25.00,"currency":"BRL", "modifier_groups":[{"name":"Proteina","is_required":true, "options":[{"label":"Frango","price":8.00}]}], "min_realisable_price":33.00} {"store_id":"if-99021","brand_id":"brand-882", "neighbourhood":"Itaquera","item_price":18.50, "note":"same brand, different neighbourhood — a city average matches neither"} {"item_id":"if-combo-77","is_combo":true, "combo_components":["item-441","item-882"], "implied_discount":"not_computed", "caution":"components a customer would otherwise buy is an assumption"}

3 of 5,204,880 store-item rows · 14 citiesstore + neighbourhood level · combos as own lines · schema v1.0

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

iFood at a glance

How we handle iFood specifically

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

Platform: iFood — dominant delivery platform, Brazil
Verticals: Restaurants, grocery, pharmacy, convenience
The trap: A national average. Regional variation is wide enough to make it meaningless
Unit: Store and neighbourhood, not city and not country
Modifiers: Priced independently. Minimum realisable price computed on a stated basis
Fees: Delivery and service fees separate from item price
Language: Portuguese retained; no translation into the record
Refresh: Daily standard; sub-daily during campaign periods

Platform specifics

What is specific to Brazil and to iFood

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

Regional variation, and why the unit is a neighbourhood

Brazilian price levels differ sharply by region and, within large cities, by neighbourhood. Income distribution, logistics cost and competitive density all vary more than they do in a comparably sized European or North American market.

A national average blends São Paulo, the northeast and the interior into a figure describing none of them.
A city average in São Paulo does much the same thing across neighbourhoods.
Store-level pricing within a chain frequently differs across a single metropolitan area.

We collect at store_id level with the neighbourhood recorded, and roll up only where you ask us to. brand_id travels alongside so a chain view is available as your choice rather than our collection level.

The panel design — which cities, which neighbourhood types — is the main scoping decision and we agree it with you rather than sweeping the country.

Modifiers carry the real price, as on any delivery platform

An item listed at R$25 with a required size or protein selection starting at +R$8 has a real entry price of R$33. For competitor tracking specifically, item price alone produces the wrong ranking rather than an imprecise one.

We deliver modifier groups as structured records with is_required, option prices and selection limits, and compute min_realisable_price with the basis recorded.

Combos and promotional bundles

Brazilian delivery menus lean heavily on combos and bundled promotions, which is a further complication: a combo is frequently cheaper than its components and it is a different product line rather than a discount on an existing one.

We record combos as their own items with is_combo flagged and, where the platform exposes the composition, the component references. We do not compute an implied discount, because the components a customer would otherwise have bought are an assumption rather than an observation.

Verticals, payment context and what we do not collect

Verticals

iFood carries restaurants, grocery, pharmacy and convenience. As on any multi-vertical platform, they behave differently and vertical is on every record. Pharmacy listings in particular carry regulatory restrictions that vary by product class, and we capture what is listed without interpreting eligibility.

Payment

Where a platform advertises payment-method-specific pricing — a PIX discount, for example — we capture it as a separate field rather than adjusting the item price. A payment-conditional price is a condition, not a price.

What we do not collect

No customer, courier or order data. No reviewer identities. No sales or order volumes, which iFood does not publish and which cannot be reliably inferred from ranking in a market where a single promotion moves position sharply.

Brazil's LGPD governs personal data and our exclusion of it predates that statute, as it does in every market.

Scope

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

Store-level pricing with neighbourhood recorded on every record
brand_id alongside, so a chain rollup is available as your choice
Modifier groups with required flags, option prices and selection limits
Minimum realisable price computed on a stated basis
Combos flagged as their own items, with components where exposed
Vertical on every record — restaurant, grocery, pharmacy, convenience
Payment-conditional pricing captured as a separate field
Delivery and service fees separate from item price
Portuguese item names retained exactly as published

❌ What we do not, and why

A national or city average presented as a market price
An implied combo discount computed from assumed components
A payment-conditional price folded into the item price
Sales, order volumes or restaurant revenue
Customer, courier, reviewer or order data

Core iFood fields

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

Field	What it is on this platform
store_id / brand_id	Collected at store level, rolled up by choice
city / neighbourhood / region	The geography that actually matters here
vertical	restaurant, grocery, pharmacy or convenience
item_id / item_name_pt	Portuguese retained as published
item_price / currency	Headline price, rarely the entry price
modifier_groups	With is_required, option prices and selection limits
min_realisable_price / price_basis	Item plus cheapest required options
is_combo / combo_components	Combos as their own line, components where exposed
payment_conditional_price / payment_method	A condition, not a price
delivery_fee / service_fee	Separate fields
observed_at	Timestamp

Use cases

What teams do with iFood data

Regional pricing strategy across Brazil

Store and neighbourhood level records, so a brand sees the actual price landscape rather than a national average that matches no market it operates in.

Competitor tracking that reflects what customers pay

Minimum realisable price rather than headline item price, which is the difference between two restaurants ranking as equivalent and ranking meaningfully apart.

Combo and bundle strategy

Combos captured as their own lines with components where exposed, showing how competitors structure bundles without an implied discount we would have had to assume.

Multi-vertical presence tracking

Restaurant, grocery, pharmacy and convenience on one panel with the vertical recorded, showing where a chain or brand appears across categories.

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

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

iFood is usually collected alongside its competitors

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

iFood data scraping: frequently asked questions

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

Because Brazilian price levels vary by region and by neighbourhood more than they do in comparably sized markets. A national figure blends São Paulo, the northeast and the interior into something describing none of them.

We collect at store level with the neighbourhood recorded, and roll up only where you ask.

Because required modifiers are unavoidable. An item at R$25 with a required selection starting at +R$8 has a real entry price of R$33.

For competitor tracking, item price alone produces the wrong ranking rather than an imprecise one — two restaurants can list identically and differ substantially once required options apply.

As their own items, flagged, with component references where the platform exposes them. A combo is a different product line rather than a discount on an existing one.

We do not compute an implied discount, because the components a customer would otherwise have bought are an assumption rather than something we observed.

Captured as a separate field with the payment method recorded, not folded into the item price. A payment-conditional price is a condition, not a price.

Folding it in would mean showing a price that only some customers can obtain.

No. iFood does not publish sales or order volumes. Ranking is sometimes used as a proxy and it is weak in a market where a single promotion moves position sharply.

We deliver ranking and availability as what they are and leave the inference to you.

We quote individually. Drivers are city and neighbourhood panel size, store count, menu depth and refresh frequency — menu depth matters because modifier groups multiply records well beyond item counts.

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

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