US Interconnection Queue Tracker & Delta Monitor

Pulls the generator interconnection queues that US grid operators (ISOs/RTOs) publish, normalizes every one of them into a single schema, and can emit a delta feed of what changed since your last run: new requests, withdrawals, status changes, and COD slips (commercial-operation dates pushed later). Built for renewables and storage developers, land scouts, and grid analysts who otherwise have to hand-scrape a different portal per region.

How it works

Each ISO ships its queue in a different format and column vocabulary. This actor fetches the raw file, page, or API per ISO, maps it through a per-ISO adapter into one flat record shape, and either returns that snapshot or diffs it against a prior one. No logins and no API keys — every source below is a public file, page, or endpoint.

ISO / RTO	Source	Format	Notes
SPP (Southwest Power Pool)	opsportal.spp.org GenerateActiveCSV	CSV	Active queue only
MISO	misoenergy.org/api/giqueue/getprojects	JSON	~3.8k projects
NYISO	NYISO-Interconnection-Queue.xlsx	xlsx	"Interconnection Queue" sheet
CAISO	publicqueuereport.xlsx	xlsx	"Grid GenerationQueue" sheet
PJM	services.pjm.com/PJMPlanningApi/api/Queue/ExportToXls	xlsx	Full queue history since 1997, ~9.3k rows. Keyless — uses the same public subscription key PJM's own public interconnection-queues page calls client-side, no PJM account needed. If PJM rotates that key the actor warns and skips PJM for that run rather than failing.
ERCOT	Monthly GIS Report, resolved from the public ERCOT MIS report list (ercot.com/misapp/GetReports.do)	xlsx	Merges the "Large Gen" and "Small Gen" tabs, ~1.85k rows. The download URL changes every month (new file, new report ID) so it's re-resolved on every run. Texas-only grid — state is hardcoded TX. Cancelled/inactive projects are published in separate ERCOT report tabs and are not merged in this version.
ISO-NE	irtt.iso-ne.com/reports/external public queue page	HTML table	Server-rendered, no login. The page 302-redirects once and requires forwarding its AspxAutoDetectCookieSupport cookie back on the follow-up request — the actor handles that automatically. ~1.75k rows.

Leave isos empty to pull all 7 live sources in one run. Adding a new ISO is one config block ({ iso, format, url, map }) in source.js.

Field coverage varies by ISO

Not every ISO publishes every field:

• project_name is null for SPP (its active-queue CSV doesn't name projects).
• queue_date (date the request was filed) is null for ERCOT's Large Gen tab — ERCOT doesn't publish that column there; for Small Gen, queue_date is a proxy (Model Ready Date, the closest milestone ERCOT publishes).
• poi for PJM is the interconnecting Transmission Owner (e.g. "PSEG"), not a specific substation — PJM's public export has no substation/POI column.
• withdrawn_date is only populated where the source carries a real withdrawal date/status: SPP, PJM, ISO-NE. NYISO, CAISO, MISO, and ERCOT don't expose one (ERCOT publishes cancellations in a separate report not merged here).
• study_phase doubles as a catch-all "current milestone/cluster" field and its meaning differs by ISO (SPP/PJM: cluster or project type; ERCOT Large Gen: folded into status instead since ERCOT has no separate phase column; ERCOT Small Gen: constant "Small Generator"; ISO-NE: the ISO's internal cluster code).

Dates are normalized to YYYY-MM-DD; month-only values snap to the first of the month.

Delta mode (legacy manual)

In delta mode the actor compares the current snapshot to a prior one YOU supply and emits only change rows. Supply the prior records directly as priorItems, or set priorKvKey to a key in the actor's key-value store — it diffs against the snapshot stored there and writes the fresh snapshot back, so a daily schedule automatically emits only what moved. A COD slip is flagged when a project's requested commercial-operation date moved later than the prior run; a withdrawal is flagged from a withdrawn date, a terminate/cancel status, or a record dropping out of the queue.

Delta & monitoring mode (automatic — no input wiring needed)

Every snapshot-mode run (the default) now also tracks itself automatically. The actor keeps its own snapshot in the key-value store under the key QUEUE_SNAPSHOT — you don't supply anything. Each run:

• Tags every queue record with is_new_since_last_run (not present in the last saved snapshot), status_changed, and previous_status (the status recorded last time, when it changed).
• Emits a synthetic row_type: "withdrawn" row for any project that was in the last snapshot but is missing from this run's pull — but only for ISOs that were fetched successfully this run. If an ISO's source errors out, its prior projects are never falsely marked withdrawn; the actor just has no fresh data for them yet.
• Emits one row_type: "iso_summary" roll-up row per ISO: total_projects, status_counts (by coarse bucket: active / withdrawn / completed / suspended / unknown), total_capacity_mw, new_count, withdrawn_count, status_changed_count.

Set deltaOnly: true to get a lean monitoring feed: unchanged rows are suppressed and the run emits only the new/status-changed rows, the withdrawn rows, and the iso_summary roll-ups — ideal for a scheduled daily or weekly monitor where you only care what moved. Leave it false (default) to keep getting the full queue every run, with these fields as bonus context.

The very first run ever (no snapshot exists yet) writes a baseline silently: every row's is_new_since_last_run stays false on that run (otherwise the entire queue would look "new"). From the second run onward, deltas are real. Row identity is iso + queue_id, or (for the rare row with no native queue ID) iso + a hash of project name + capacity — stable across runs as long as the project's name/capacity don't change.

This monitor engine is completely independent of the legacy delta mode above — existing priorItems/priorKvKey workflows are untouched.

Example input — snapshot, multiple ISOs

{ "isos": ["PJM", "ERCOT", "ISO-NE"], "mode": "snapshot", "maxResults": 5000 }

Example input — delta (scheduled monitoring)

{ "isos": ["SPP"], "mode": "delta", "priorKvKey": "spp_last_snapshot" }

Example input — automatic monitor mode (deltaOnly)

{ "isos": ["SPP", "MISO", "PJM"], "mode": "snapshot", "deltaOnly": true }

No priorKvKey needed — the actor tracks its own snapshot under the key-value-store key QUEUE_SNAPSHOT. Run this on a daily or weekly Apify Schedule to get only new projects, status changes, and withdrawals since the last run.

Output fields

Every row: iso, queue_id, project_name, interconnection_type (generation / storage / load, inferred from fuel and type text), fuel_type, capacity_mw, county, state, poi (point of interconnection), status, queue_date, requested_cod, withdrawn_date, study_phase, source_url, retrieved_at.

Legacy delta-mode rows add change_type (new / withdrawn / status_change / cod_slip), plus old_status / new_status and old_requested_cod / new_requested_cod.

Automatic monitor-mode fields (present on every snapshot-mode row, nullable so nothing existing is disturbed): row_type (queue_record / withdrawn / iso_summary), is_new_since_last_run, status_changed, previous_status. Synthetic withdrawn rows also carry previous_requested_cod. Synthetic iso_summary rows carry total_projects, status_counts, total_capacity_mw, new_count, withdrawn_count, status_changed_count instead of the per-project fields.

Who uses it

• Renewables and storage developers watching competitor projects enter and leave the queue and catching COD slips that free up capacity or signal congestion.
• Land agents and site scouts spotting new projects by county/state near active points of interconnection.
• Energy consultants building cross-ISO capacity and fuel-mix views without scraping each portal.
• Transmission planners and investors tracking queue velocity, withdrawals, and study-phase progression.
• Developers running a weekly automated monitor on a shortlist of ISOs to get alerted the moment a competitor's project is withdrawn or a status milestone changes, without maintaining their own diff logic.

Use as an MCP tool

A Pay-Per-Result API callable by AI agents through mcp.apify.com. An agent can pull a region's queue, filter by fuel or capacity, and hand rows to a mapping or outreach step.

FAQ

How do I track interconnection queue changes? Run snapshot mode (the default) with deltaOnly: true — the actor automatically remembers the last run's snapshot (key-value-store key QUEUE_SNAPSHOT) and emits only new projects, status changes, and withdrawals since then. No extra input required.

How do I get queue withdrawal alerts? Same as above — every run marks projects missing from the latest pull as row_type: "withdrawn", with the project's last-known status and requested COD attached. Schedule the actor daily or weekly and pipe deltaOnly output to your alerting/webhook of choice.

How do I monitor for new interconnection requests (legacy)? You can still run delta mode on a schedule with a priorKvKey for the original manual-diff workflow; each run emits only new / withdrawn / status_change / cod_slip rows.

Which ISOs are covered? All 7 major US grid operators: SPP, MISO, NYISO, CAISO, PJM, ERCOT, and ISO-NE.

Do I need an API key? No. Every source is public and keyless, including PJM (uses PJM's own public-page subscription key) and ERCOT (resolves the current month's public GIS Report automatically).

How is it billed? One queue record, one synthetic withdrawn row, one iso_summary row, or one legacy change record is one dataset item (one Result event). Use deltaOnly: true to keep monitoring runs lean and low-cost.