Platform · Grab

Grab Data Scraping Services

Where delivery promise moves with transport demand, because the fleet is shared with ride-hailing.

Grab data scraping is the automated collection of publicly visible Grab data across Southeast Asian markets — food and mart verticals kept separate, menus at item and modifier level, and delivery promise captured with time of day because a fleet shared with ride-hailing makes promise times move with transport demand, not just kitchen load.

On a delivery-only platform, promise time tracks kitchen and courier load. Here the courier fleet also serves ride-hailing, so promise times move with rush hour in a way delivery-only platforms do not show.

Get a free sample See sample data

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

grab_dayparts.jsonl LIVE FEED

{"grab_entity_id":"gb-771204", "vertical":"food", "market":"SG","currency":"SGD", "city":"Singapore","delivery_zone":"central", "serves_zone":true, "menu_item_id":"mi-4481", "base_price":12.90, "delivery_promise_min":22, "observed_at":"2026-08-10T15:10Z", "daypart":"off_peak", "delivery_fee":2.99, "surge_fee":0.00} {"grab_entity_id":"gb-771204", "delivery_promise_min":47, "observed_at":"2026-08-10T11:40Z", "daypart":"lunch_peak", "surge_fee":1.80, "note":"shared fleet — promise more than doubles at peak"}

2 of 3,884,100 rows · markets: 5peak and off-peak both captured · schema v2.2

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

Grab at a glance

How we handle Grab specifically

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

Platform: Grab food and mart verticals across Southeast Asian markets
Distinctive behaviour: Shared fleet — promise times move with transport demand
Consequence: Time-of-day effects are stronger than on delivery-only platforms
Verticals: Food and mart collected separately, each with its own schema
Market: A dimension on every record, with currency
Fee stack: Delivery, service and surge fees decomposed as displayed
Refresh: Multiple times daily, timed to capture peak and off-peak
Region: Southeast Asia

Platform specifics

What makes Grab data different from delivery-only platforms

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

A shared fleet makes time of day a first-class field

Grab's courier capacity also serves ride-hailing. That means delivery promise and surge fees respond to transport demand as well as to food demand, and the two peaks do not perfectly coincide.

Why that changes collection design

Promise times swing more across the day than on delivery-only platforms.
Surge fees respond to fleet scarcity, which can be driven by commuting rather than by meal demand.
A single daily observation is close to meaningless for promise and fee fields.
Off-peak and peak are different markets for competitive comparison.

We capture delivery_promise_min and each fee component with observed_at and a derived daypart, and we schedule collection to hit both peak and off-peak rather than sampling at a convenient hour.

The honest limit: we cannot attribute a promise change to ride demand versus food demand, because fleet allocation is not published. We report the observation with its time; the cause is not observable and we will not model it.

Food and mart are different datasets

Grab spans food delivery and a mart or convenience vertical. As on every multi-vertical platform we collect, they share an app and share nothing that matters to a schema.

Food is menu items with modifier trees and kitchen-driven availability.
Mart is packaged SKUs with pack sizes, unit pricing and store-level ranging.

Merged, modifier trees are null on every mart row and pack sizes are null on every food row. We collect each with its own schema, joining on market and city where you want both.

Mart pricing also frequently carries a markup over the underlying retailer's shelf price. Where we collect that retailer too, the markup becomes measurable rather than assumed — the structure we handle on Instacart and DoorDash.

Multi-market, and the markets are not alike

Grab operates across Southeast Asian markets with different currencies, different competitive sets and different price levels. A combined regional figure averages markets that behave differently.

Currency and price level differ substantially, so local currency must be authoritative.
Competitive sets differ. The rival in Singapore is not the rival in Jakarta.
Fee structures and minimum orders differ by market and city.
Vertical availability differs — not every vertical operates in every market.

Every record carries market and currency, with conversion derived rather than baked in so cross-market analysis can be recomputed against any rate. City and delivery zone are recorded too, since coverage varies within cities as on every delivery platform we collect.

Scope

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

Delivery promise and fees with observation timestamp and derived daypart
Collection scheduled to capture both peak and off-peak
Food and mart verticals collected separately with their own schemas
Menu items with modifier trees for food; pack and unit pricing for mart
Markup over retailer shelf price where we also collect the retailer
market and currency on every record, with conversion derived not baked in
City and delivery zone with a serves-zone flag
Fee components decomposed at every observation
Ratings and review text without reviewer profiles

❌ What we do not, and why

Attribution of a promise change to ride demand versus food demand, which is not observable
Commission rates or platform economics
Order volumes, driver data or fleet allocation
Prices requiring a signed-in or membership session
Reviewer names, profiles or review histories

Core Grab fields

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

Field	What it is on this platform
grab_entity_id	Merchant or store identifier, the record key
vertical	food or mart, kept separate
market / currency	Country and currency, both mandatory
city / delivery_zone / serves_zone	Geography and whether this zone is served
delivery_promise_min	Displayed promise at the observation time
observed_at / daypart	When the observation was taken and its derived daypart
delivery_fee / service_fee / surge_fee	Fee components at every observation
menu_item_id / base_price / modifier_price	Food item and modifier pricing
sku / pack_size / unit_price_computed	Mart item, pack and unit price
price_vs_retailer_shelf	Markup where we also collect the underlying retailer
min_order_value	Minimum basket for this market and zone

Use cases

What teams do with Grab data

Daypart-aware delivery benchmarking

Promise and fees captured with timestamps and dayparts show how service level moves through the day, which a single daily observation cannot.

Peak versus off-peak competitive comparison

Collection scheduled across both peak and off-peak lets comparison be made within a daypart rather than across two different market states.

Markup measurement on the mart vertical

Where the underlying retailer is also collected, the markup over shelf price is measurable rather than assumed.

Per-market Southeast Asian analysis

Market and currency on every record with derived conversion keep comparison valid across markets with very different price levels.

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

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

Grab is usually collected alongside its competitors

Almost nobody buys a single platform in isolation. Grab 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 delivery data covers, and a Grab-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

Grab data scraping: frequently asked questions

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

Because the courier fleet also serves ride-hailing, so delivery promise and surge fees respond to transport demand as well as food demand — and the two peaks do not perfectly coincide.

Promise times swing more across the day than on delivery-only platforms, which makes a single daily observation close to meaningless for those fields.

No. Fleet allocation is not published, so attributing a promise change to ride demand versus food demand is not observable.

We report the observation with its timestamp and daypart. Modelling the cause would be a guess presented as insight, and the timestamped observation is the honest deliverable.

Because they share an app and nothing that matters to a schema. Food is menu items with modifier trees; mart is packaged SKUs with pack sizes and unit pricing.

Merged, modifier trees are null on every mart row and pack sizes are null on every food row — a table that looks large and is mostly empty.

Multiple times daily, timed to hit both peak and off-peak rather than sampled at a convenient hour. Promise and fee fields move too much across the day for a single observation to represent them.

Menu prices move less, so we tier it: prices daily, promise and fees several times daily at scheduled dayparts.

The Southeast Asian markets where Grab operates, with market and currency on every record. We collect the ones you need.

A combined regional figure averages markets with very different price levels and competitive sets, so we do not produce one by default.

We quote individually. Drivers are market count, merchant count, zone coverage, how many verticals, and observation frequency — the daypart requirement means more observations per day than a typical delivery engagement.

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

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