Platform · GeM (Government e-Marketplace)

GeM Tender Data Scraping

Q: Do you handle corrigenda and extensions?

Yes. We keep a revision_count and retain superseded versions rather than overwriting, so a bid whose quantity or closing date changed is visible as having changed. Overwriting would make a bid appear to have always carried its latest terms, which breaks any historical analysis and any audit of what you saw when you decided not to bid.

The field everyone gets wrong here is consignee location. It is not the buyer's location, and filtering on the wrong one returns the wrong tenders.

GeM tender data scraping collects publicly listed bids from India's Government e-Marketplace — bid reference, category, quantity, closing datetime, buying organisation and consignee location as a separate field from the buyer. A single ministry can raise one bid with consignees across eleven states, so conflating the two returns tenders in the wrong geography.

Buyers ask for GeM by state, ongoing bids only, and a link to the bid document. All three are answerable, and one of them needs a caveat that most vendors leave out.

Get a free sample See sample data

Free pilot on your own GeM (Government e-Marketplace) list, returned in 24 hours. No card, no trial clock — and you keep the sample data either way.

gem_bids.jsonl LIVE FEED

{"bid_number":"GEM/2026/B/7712049", "bid_title":"Supply of laboratory consumables", "buyer_organisation":"Ministry of Example", "buyer_state":"Delhi","buyer_city":"New Delhi", "consignees":[{"state":"Maharashtra","city":"Pune","quantity":400}, {"state":"Gujarat","city":"Ahmedabad","quantity":250}], "bid_end_datetime":"2026-09-04T15:00:00+05:30", "is_ongoing":true, "ongoing_basis":"bid_end_datetime vs collected_at", "collected_at":"2026-08-25T06:00:00+05:30", "document_reachable_anonymously":true} {"bid_number":"GEM/2026/B/8890120", "document_url":"https://…/bid-doc", "document_reachable_anonymously":false, "note":"URL is public, the file needs a session — we do not sign in"} {"bid_number":"GEM/2026/B/9902211", "revision_count":2, "note":"corrigendum changed quantity — earlier versions retained"}

3 of 412,880 bid rows ongoing onlyconsignee separate from buyer · doc reachability flagged · schema v1.0

Independence and trademarks. Actowiz Solutions is not affiliated with, endorsed by or connected to GeM (Government e-Marketplace) or its owners. GeM (Government e-Marketplace) 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

GeM (Government e-Marketplace) at a glance

How we handle GeM (Government e-Marketplace) specifically

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

Source: GeM — Government e-Marketplace, India
The critical distinction: Consignee location ≠ buying organisation location
Consequence: One bid can carry consignees in many states. Both are recorded
Closing time: Datetime with timezone, because 15:00 IST is a hard boundary
Ongoing filter: Derived from closing datetime against collection time, not a scraped label
Documents: URL captured. Reachability flagged, because some require a session
Session: Anonymous only. No account creation, no credentials
Refresh: Several times daily; hourly near closing windows

Platform specifics

What is specific to GeM

These are the reasons a GeM (Government e-Marketplace) dataset needs its own handling rather than a shared retail schema.

Consignee location is a separate field, and it is the one you filter on

This is the difference between a usable GeM feed and an unusable one.

On GeM, the buying organisation raising the bid and the consignees receiving the goods are frequently in different places. A central ministry in Delhi can raise one bid with delivery to eleven states.

Filter on buyer location and you get tenders whose goods go somewhere else entirely.
Filter on consignee location and you get the tenders your local operation can actually service.
A bid with multiple consignees should appear for each relevant state, not once against the buyer's.

We deliver buyer_state and buyer_city alongside a consignees array, each with its own state, city and quantity. Where you want a flat file, we can explode to one row per consignee with consignee_row: true so the duplication is visible rather than silently inflating your bid count.

Ongoing means a datetime comparison, not a label

The request is almost always for ongoing bids only. That sounds like a filter and it is actually an arithmetic problem.

Closing datetime carries a timezone. A bid closing at 15:00 IST is open at 14:59 and closed at 15:01, and your systems may not be in IST.
Extensions happen. A closing date can move, so a bid captured as closing tomorrow may not close tomorrow.
Corrigenda change terms mid-flight, including quantity and specification.

We record bid_end_datetime in ISO-8601 with the offset, collected_at, and a derived is_ongoing that states which of the two it was computed against. We also keep a revision_count and retain superseded versions rather than overwriting, so a bid that changed is visible as having changed rather than appearing to have always said the new thing.

Document URLs are public. The documents are not always

The third part of the usual request is a direct download link to the bid document. The URL is generally public and we capture it.

Whether the file behind it downloads without a signed-in session varies by tender, and that is where a vendor either tells you or does not.

Some documents download anonymously. Those we can retrieve where the scope includes it.
Some require a session. We record document_reachable_anonymously: false and do not sign in.
Some are behind a captcha or a per-document step, which is a separate state again.

We report the anonymously reachable share across your tracked categories before quoting. If it is low in your category, a workflow built on automatic document retrieval is not viable and you should know that before designing one.

Scope

What we collect on GeM (Government e-Marketplace), 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

Bid reference, title, category and quantity as listed
Buying organisation with its own state and city
Consignee array, each with state, city and quantity
Optional explode to one row per consignee, flagged as such
Bid end datetime in ISO-8601 with timezone offset
Derived ongoing flag, with the comparison basis stated
Revision count, with superseded versions retained
Document URL, with anonymous reachability flagged
MSE and startup exemption indicators where published

❌ What we do not, and why

Anything requiring a GeM login or seller account
Bid documents behind a session or a per-document verification step
Bidder identities, submitted bids or award values before publication
Personal data of officials or bidders
Any bid submission, expression of interest or portal interaction

Core GeM (Government e-Marketplace) fields

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

Field	What it is on this platform
bid_number	The GeM bid reference, the record key
bid_title / category	As listed
quantity / unit	Total quantity and its unit
buyer_organisation / buyer_state / buyer_city	Who is buying, and where they are
consignees	Array of state, city and quantity — the field you filter on
consignee_row	True on exploded rows, so duplication is visible
bid_end_datetime	ISO-8601 with offset. A hard boundary, not a date
is_ongoing / ongoing_basis	Derived, with the comparison stated
revision_count / superseded_by	Corrigenda tracked, originals retained
document_url / document_reachable_anonymously	URL, and whether the file is actually retrievable
collected_at	Observation time, required to interpret the ongoing flag

Use cases

What teams do with GeM (Government e-Marketplace) data

State-level bid discovery that returns the right tenders

Filtering on consignee location rather than buyer location, so a regional supplier sees the bids whose goods actually come to their territory instead of every bid raised by a Delhi ministry.

Ongoing-bid pipelines with a real deadline

Bid end datetime with timezone and a derived ongoing flag computed against a stated collection time, so a pipeline never surfaces a bid that closed while the file was in transit.

Category and quantity monitoring

Bid volumes by category and consignee state over time, which shows where public demand is concentrating before it appears in any published summary.

Document workflow feasibility assessment

The anonymously reachable share reported per category before build, so an automated document workflow is only commissioned where the documents can actually be retrieved.

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

Send us a GeM (Government e-Marketplace) 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.

GeM (Government e-Marketplace) is usually collected alongside its competitors

Almost nobody buys a single platform in isolation. GeM (Government e-Marketplace) 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 government & tender data covers, and a GeM (Government e-Marketplace)-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

GeM (Government e-Marketplace) data scraping: frequently asked questions

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

Because the buying organisation and the consignees are frequently in different places. A central ministry in Delhi can raise one bid with delivery to eleven states.

Filter on buyer location and you get tenders whose goods go elsewhere. Filter on consignee location and you get the ones your operation can service. We deliver both, and can explode to one row per consignee with a flag so the duplication is visible.

Yes, and it is a datetime comparison rather than a label. We record bid_end_datetime in ISO-8601 with the timezone offset, record collected_at, and derive is_ongoing stating which two values it compared.

That matters because a bid closing at 15:00 IST is open at 14:59, and a feed that hands you a date without a time or a zone cannot tell you which side of that you are on.

The URL, always. The file itself, only where it downloads without a signed-in session — and that varies by tender.

We flag document_reachable_anonymously on every record and report the reachable share across your categories before quoting. If it is low in your category, an automated document workflow is not viable and you should know that before designing one.

Yes. We keep a revision_count and retain superseded versions rather than overwriting, so a bid whose quantity or closing date changed is visible as having changed.

Overwriting would make a bid appear to have always carried its latest terms, which breaks any historical analysis and any audit of what you saw when you decided not to bid.

No. Bidder identities and submitted bids are not public before award, and we do not collect personal data about officials or bidders in any case.

Where award information is published we can collect it as published, but that is a different dataset and it arrives after the decision rather than before it.

We quote individually. Drivers are category breadth, consignee-state scope and refresh frequency — frequency matters near closing windows, where hourly is sometimes justified and daily is not.

One scoping call, a free pilot within 24 hours including the document-reachability share, then a fixed monthly quote. Request a quote.

See real GeM (Government e-Marketplace) 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