How accurate are EnergyMap APIs?

Energy data is only useful if you trust it. We run a collection pipeline that scrapes the Indian Energy Exchange (iexindia.com) every 30 minutes, parses ninety-six 15-minute time blocks per market, and serves the result at api.energymap.in/api/intelligence/iex-market-data. A lot can go wrong between “raw HTML on a vendor page” and “JSON returned by your API.” This post is how we check.

Matching iexindia.com to four decimal places across an entire day is the floor, not the ceiling.

The test

We wrote a small provenance script (scripts/iex_provenance_check.py) that behaves the way a careful human would. For a given delivery date it:

1. Hits our production API and pulls every row.
2. Fetches the same day's snapshot from iexindia.com (DAM and RTM market-snapshot pages — exactly the URLs a grid operator would open in a browser).
3. Buckets both datasets by 15-minute block in IST, then compares four fields per block: MCP (₹/MWh), MCV (MW), total purchase bid (MW), total sell bid (MW).
4. Flags any value that differs from the website by more than 0.01 percent.

A full day of DAM = 96 blocks × 4 fields = 384 data points. RTM adds ten spot-check blocks spread across the 24-hour window.

The result

Run on the 23 April 2026 delivery date, against api.energymap.in:

Every single price and volume the API returned matched the IEX website exactly — not to 2 decimals, exactly, down to the hundredths place that IEX publishes.

What a spot-check looks like

Eight blocks picked across the day, values pulled from our API. Open the IEX DAM snapshot in another tab and compare:

The honest caveats

Parity on values does not mean the pipeline has no rough edges. The test surfaced three things worth saying out loud.

• RTM has a real-time lag. The Real-Time Market settles every 15 minutes; our scraper runs every 30. For today's date the IEX site showed 96 RTM blocks while our API had 82 — a 14-block / roughly 3.5-hour tail that we haven't fetched yet. Every block we had matched, but if you need the last ninety minutes of RTM, you should hit IEX directly until we tighten the cron cadence.
• Duplicate rows per block. Each timestamp can return two rows — one from the live snapshot source and one from the historical backfill — with slightly different region casing (“All India” vs “ALL_INDIA”). The values are identical; the shape is noisy. Downstream code must dedupe. We're fixing this at the serving layer.
• The market_type query filter is loose. Asking for DAM currently returns RTM rows too. Clients that rely on the response field rather than the query parameter are unaffected; clients that trust the filter will double-count. Patch in flight.

Reproduce this yourself

The script is in the public repo. You can run it against our production API on any day the IEX website still shows:

# 1. scrape the iexindia.com snapshot table into a CSV:
#    columns -> block,time,mcp,mcv,buy,sell  (one row per 15-min block)
# 2. point the script at the truth file:
python scripts/iex_provenance_check.py \
    --api https://api.energymap.in \
    --truth ./iex_website_dam.csv \
    --date 2026-04-23 \
    --market DAM \
    --out ./iex_provenance_report.json

Carbon intensity: why numbers differ across dashboards

Customers sometimes compare our Western-zone carbon-intensity value against other public carbon-intensity dashboards for the Indian grid and ask why ours is higher. Fair question. The answer isn't that one source is right and the other is wrong — it's that carbon intensity has four independent axes of methodology choice, and different platforms pick different defaults on every one of them. Here's the exact arithmetic, using the Western zone on 23 April 2026 at 00:00 UTC (05:30 IST — pre-dawn, coal-dominant).

Every one of those knobs is now a query parameter on /developer/v1/carbon-intensity/by-zone: ?factors=direct, ?accounting=consumption, ?include_rooftop=true. Default to our defaults if you want the strictest accounting of India's fleet emissions; flip the switches if you want numbers aligned with the direct-combustion / consumption-accounting convention that most public grid-carbon dashboards use. Both are honest — the methodology just has to travel with the number, and the knobs make that methodology explicit.

For the full math, per-fuel factor tables, source citations, and worked examples, see our companion post: How we compute carbon intensity.

Why we do this

A developer building a battery-storage model, a journalist writing about peak prices, a policymaker evaluating market design — they all need to be able to audit the numbers we serve. Matching iexindia.com to four decimal places across an entire day is the floor, not the ceiling. We'll publish these checks for the other data in the Atlas — SLDC demand, CEA generation, IMD weather — in the weeks ahead, one stream at a time.

If something does not line up, tell us. Email hello@energymap.in and we'll run the check against whatever date and market you're looking at.