Is there an API for India's quick-commerce apps? A straight answer

What does the API return?

Each record is one reading of one product page, at one pin code, at one time. A price reading carries:

• the app it came from and that app’s own product id;
• the pin code it was read for, and when the page was read;
• the title, brand and pack size exactly as the app showed them;
• the selling price and the MRP, in paise;
• whether the product was in stock as shown;
• the address of the page it came from, and the text each figure was read from.

A price that could not be read comes back empty, never as zero. A page with no stock signal comes back with stock left empty. Unknown stays unknown, so a gap in the data never looks like a real price or a real stockout.

A stock check at a pin code returns one of three states: in stock, out of stock, or unknown. An unknown answer carries its reason, for example that the newest reading is older than 48 hours, or that there is no reading at that pin code in the last 30 days, along with the time of the reading it used. The full field list is in the commerce data reference.²

Which apps does it cover?

On 31 Oct 2026, 1:43 pm IST, /data listed the “Prices and stock by pin” dataset as live, with coverage “6 sources, 677 pins held, fresh read at any pin on Blinkit, 1 behind”. Freshness on the card: Daily, last updated 31 Oct 2026, 1:39 pm IST. The sources are Blinkit, Zepto, Instamart, JioMart and DMart. The commerce data page groups them with the other shopping datasets.

The public catalogue breaks that down by app, as measured on 31 Oct 2026, 1:43 pm IST:

“Held” means Rewalto has readings from that app at that pin code; it is a count of places read, not a promise about every pin code in a city. BigBasket is read at national level, so its prices are not tied to a pin code. When you compare apps, compare them at pin codes both of them cover, and treat a pin code one app covers and another does not as a gap in the data rather than a difference in the shelf.

Each app has its own page with its fields, sample records and current coverage: Blinkit data by pin code, Zepto data by pin code and Instamart data by pin code.

Across every dataset, not only this one, the data coverage page lists each app and store and the pin codes held, with the date it was checked.¹ Rewalto is not affiliated with, or speaking for, any app.

How many pin codes, and how fresh?

677 pin codes held, as of 31 Oct 2026, 1:43 pm IST. Not every app is read at every pin code: the coverage above shows each app’s own count, and /data shows each source and its readings for the previous day. For Blinkit, a fresh reading can be asked for at any pin code, not only the ones already held. For a pin code Rewalto has not read, the API says so instead of guessing.

Freshness is part of every answer. A stock answer whose newest reading is older than 48 hours comes back unknown, with the reason that it is stale, rather than as a stale yes or no. Every record carries the time its page was read, so you can apply a stricter rule of your own.

Read the coverage line before you plan around it. A count of pin codes held tells you where readings exist, not that every product was read at each of them on every day. For a plan that depends on a few pin codes, look each one up in the coverage list and check the day of its newest reading. If a pin code you need is missing, ask through the catalogue rather than reading the gap as an empty shelf. If two apps disagree at one pin code, check that both readings are from the same day before you treat it as a difference in price or stock. When you share a figure from the API with a colleague, keep the reading time beside it, so they can tell how old it was when they used it.

Is it the apps' own API?

No. Rewalto collects public data itself, from public pages, and serves it through its own API. That is how /data describes the source of this dataset (26 October 2026).¹ This page does not describe the apps’ own seller, partner or developer programmes; check each app’s site for those.

The difference matters when you plan. A reading shows what a public page displayed at a pin code and a time. It is evidence of the shelf a shopper saw, not a record from inside an app’s systems.

Each catalogue entry also carries its source and usage notes. Read them before you plan to show the data inside a product of your own or pass it to a client, and keep the source page and reading time beside any figure you publish, so a reader can see where it came from and when.

Is there an MCP server?

Yes, in preview. Rewalto’s MCP server is at mcp.rewalto.com/mcp. It works on the same data contract as the REST API, with the same credentials and the same approval rules. An agent connection does not bypass scopes or credit review.

The API, CLI and MCP docs list which client setups, sign-in options and connection tests are available for your agent.² Before you connect an agent, read the guide to the quick commerce MCP server.

How do I make a first call?

Start without a key. The version route needs no credentials, and the public catalogue is free, so you can confirm the dataset is live and see its coverage before you spend anything.

# No key needed: which release answered, and is the dataset live?
curl --fail-with-body "https://api.rewalto.com/v1/version"
curl --fail-with-body "https://api.rewalto.com/v1/catalogue/products?status=live"

# With a key, kept on your server: share in stock per app at one pin code
curl --fail-with-body -G "https://api.rewalto.com/v1/data/availability/pin" \
  -H "Authorization: Bearer $REWALTO_API_KEY" \
  --data-urlencode "pincode=<six-digit pin code>"

# Listings for a product read at that pin code in the last 30 days
curl --fail-with-body -G "https://api.rewalto.com/v1/data/listings/search" \
  -H "Authorization: Bearer $REWALTO_API_KEY" \
  --data-urlencode "q=<product words>" \
  --data-urlencode "pincode=<six-digit pin code>" \
  --data-urlencode "limit=10"

Authenticate with a bearer token: either a session token or an organisation API key. Keep the key on your server, never in a browser or a shared prompt. The first request guide walks through it, and the developer docs list every route. For an overview of what the API is for, start at Rewalto for developers.

A worked example: one product at one pin code

Say a brand team wants to know whether its 1 kg atta is on the shelf at one pin code in Bengaluru, and at what price, on each app that serves it. The calls follow the order a person would ask the questions.

1. Check the catalogue, free, to confirm the prices and stock dataset is live and to see which apps hold readings at that pin code.
2. Ask for the share in stock per app at the pin code. This tells you which apps were read there recently, and how much of each shelf was unknown, before you look at one product.
3. Search listings for the product words at that pin code. Compare each result’s title and pack size with the product you mean; a 500 g pack or a combo is a different product.
4. Ask for the stock state of each matching listing. Keep the reading time with every answer, and keep unknown answers as unknown.

The result is a small, dated table: app, listing, price, MRP, stock state and reading time at one pin code. It answers the question that was asked, and it shows plainly where the data has nothing to say.

How do I match one product across apps?

Each app gives a product its own id, and the same pack can carry a slightly different title on each app. Rewalto returns the title, brand and pack size exactly as each app showed them, so the matching is yours to check before you compare prices.

Match on three things together: the brand, the pack size with its unit, and the words that name the variant. A 1 kg pack and a 5 kg pack of the same atta are two products. So are a single pack and a pack of two, a refill and a jar, or a regular and a sugar free version. When one app lists a combo and another lists the single pack, leave the pair out of a price comparison rather than dividing the combo price by a guess.

Keep each app’s own product id beside your match. If a title changes later, the id lets you see that it is still the same listing, and it lets someone else repeat your comparison from the same records. When you are not sure two listings are the same product, say so in your table instead of forcing a match: a short list of clean pairs is more useful than a long list with a few wrong ones.

Price per unit helps when pack sizes differ, but only when both packs state their size in the same unit. Work it out from the selling price and the stated size, and keep the original figures next to it, so a reader can see how the comparison was made.

What does a read cost?

Reads are charged in credits, for data delivered:²

• Listings and price readings: 1 credit per 10 records delivered, rounded up.
• Stock checks: 1 credit per 10 rows with a known state. Unknown rows cost nothing.
• An empty result costs nothing, and re-reading the same records within 7 days is free.
• The catalogue and the version route are free.
• Without enough credits, the API says the credits are used up and returns no data.

What can it not do?

• Place orders or act on a seller account. The documented data routes read listings, prices and stock. None place orders, change listings or manage a seller account.
• Show daily stock history yet. “Stock state” on /data is built and checked, but /data says its daily run is not switched on yet (26 October 2026).
• Answer for a pin code it has not read. You get no listings or an unknown state, never a guess.
• Measure sales or demand. A reading shows what a page displayed. It does not show how much sold, or why a product was out of stock.

How to judge any quick-commerce data API

Whichever provider you use, ask the same questions before you build on it. The India data API guide goes further on choosing records and access.

1. Coverage: which sources and which pin codes, and is that measured and dated?
2. Freshness: when was each record read, and is that time in the response?
3. Evidence: does each record point back to the page it came from?
4. Unknowns: does the API tell you when it does not know, or does it fill gaps with zeros?
5. Cost: are you charged for empty or unknown answers?
6. Terms: what may you do with the data once you have it?

If you only need to check one brand at one pin code, you may not need an API at all: the free pin-code availability tool answers that in a browser.

Where to go next

For one app at a time, read the Blinkit, Zepto and Instamart scraper alternatives. Before you buy, use five checks on coverage and freshness and how to choose a shelf data provider. For marketplaces rather than quick commerce, see marketplace product data.

Ready-made bundles are on dataset packs, and every other guide is listed on Guides.

Questions worth settling

Notes

1. Rewalto /data and the public catalogue (“Prices and stock by pin” and its per-app coverage), read each time this page is served, with the date shown beside each figure, and the data coverage page. Back to text
2. Rewalto developer docs and the API contract, version 0.96.0, read 26 October 2026: quickstart, data, API, CLI and MCP and errors. Back to text