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	All three active tabs merged: "Interconnection Queue", " Cluster Projects" (the post-2024 cluster queue) and "Load Projects" (load interconnections, the only source in the federation that populates interconnection_type: "load"). ~264 rows.
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 declared field, in full. All fields are nullable — null means not published / not checked, never "checked and zero".

Per-project fields (row_type: "queue_record")

Field	What it is
iso	Grid operator the record came from: SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE
queue_id	ISO-assigned interconnection queue / project number
project_name	Project name where the ISO publishes one
interconnection_type	Closed vocabulary: generation, storage, load, transmission
request_category	Closed vocabulary: generator_interconnection, transmission_service, upgrade, load, affected_system
fuel_type	Fuel / technology as published (codes decoded per ISO)
capacity_mw	Requested / net capacity in MW
nameplate_capacity_mw	Second published capacity figure (nameplate, winter net, MW in service) — compare with capacity_mw for seasonal or ERIS/NRIS derating
storage_capability_mwh	Energy storage capability in MWh (NYISO only)
county	County or nearest town of the point of interconnection
state	State of the point of interconnection
zone	Load / planning zone or study group
poi	Substation, line, or station where the project connects
transmission_owner	Interconnecting transmission owner or utility
developer	Developer / interconnection customer (NYISO and ISO-NE only)
service_type	Interconnection service requested, in the ISO's own vocabulary (ER/NR, ERIS/NRIS, Capacity or Energy)
status	Current queue status as published by the ISO
study_phase	Study phase or cluster the request sits in
queue_date	Date the request entered the queue (YYYY-MM-DD)
requested_cod	Requested commercial-operation / in-service date
withdrawn_date	Date the request was withdrawn, where the source publishes one
withdrawn_remarks	Free-text remark (PJM withdrawal remarks, SPP cause of delay, ERCOT comment, MISO post-GIA status, ISO-NE jurisdiction, NYISO load end-use)
source_dataset	Which feed or workbook tab inside the ISO the row came from
source_url	The exact endpoint or monthly file the record was pulled from
retrieved_at	ISO 8601 timestamp of this run

Monitor fields (snapshot mode, on every row)

Field	What it is
row_type	queue_record, withdrawn (synthetic — a project that vanished from the latest pull), or iso_summary
is_new_since_last_run	Not present in the last saved snapshot
status_changed	Status differs from the last saved snapshot
previous_status	Status recorded last time, when it changed
previous_requested_cod	withdrawn rows: requested COD recorded before the project disappeared
iso_monitor_baseline	True on the first run that ever saw this ISO — its records are baselined, not reported as new

Per-source status (on every row)

Field	What it is
iso_status	ok (fetched in full, passed every live drift check), truncated, not_fetched, or unavailable
isos_requested	Comma-separated list of every ISO this run asked for
isos_ok	ISOs that answered in full
isos_unavailable	ISOs that failed, drifted, were truncated, or were never fetched — null when the whole federation answered
run_is_partial	True when at least one requested ISO did not answer in full

Roll-up fields (row_type: "iso_summary", one per requested ISO)

Field	What it is
total_projects	Queue records for this ISO this run — null, not 0, when the ISO did not answer
status_counts	Counts by coarse bucket: active / withdrawn / completed / suspended / unknown
total_capacity_mw	Sum of capacity_mw across this ISO's records
capacity_missing_count	How many of this ISO's records published no capacity at all and contributed nothing to that sum
new_count, withdrawn_count, status_changed_count	Monitor counts for this ISO
iso_row_count, iso_fetched_row_count	Rows emitted, and rows retrieved upstream before any maxResults cut
iso_truncated	The run-wide maxResults cap cut this ISO short
iso_error	Why this ISO did not answer in full
iso_data_as_of	Publisher-declared as-of date (SPP CSV preamble, ERCOT monthly report posting date)
iso_source_url	The exact endpoint or monthly file this ISO was read from
withdrawal_inference_eligible	Whether absence from this pull may be read as a withdrawal for this ISO

Legacy delta-mode fields

change_type (new / withdrawn / status_change / cod_slip), old_status, new_status, old_requested_cod, new_requested_cod.

Reliability: what happens when a source goes down

Seven federated sources means a partial answer is the normal failure mode, not the exception. Three of them (ERCOT's monthly report URL, ISO-NE's HTML table, PJM's public subscription key) are scraped or derived formats where an upstream change returns HTTP 200 and a silently empty parse.

Every ISO is therefore checked live, on every run, against a band measured on 2026-08-01: row count inside its envelope, queue_id and status fill rates above their floors, every interconnection_type and request_category inside its closed vocabulary, ERCOT rows inside Texas, and — for the two sources that publish one — a declared as-of date no older than its limit. A source that fails any of these is reported iso_status: "unavailable"; it is not reported as an empty queue. Every measured value is written to the run log.

Consequences, all of them deliberate:

• A partial run is visible on the row. run_is_partial, isos_ok and isos_unavailable are stamped on every record, and each ISO that did not answer gets its own iso_summary row with total_projects: null and the upstream error.
• Withdrawal inference is disabled for any ISO that did not answer in full. A project that is missing because its ISO was unreachable is not a withdrawal. This also covers an ISO cut short or skipped by the maxResults cap.
• The snapshot is merged forward, never overwritten. Prior entries for an ISO that did not answer are carried over, so that ISO does not report its whole queue as brand-new on the following run.
• The first sighting of an ISO is a baseline. Adding an ISO to an existing monitor does not fabricate a flood of "new project" events.
• If every requested ISO fails, the run fails. Nothing is emitted and nothing is billed.
• An unrecognised ISO code fails the run with the list of valid codes, rather than being silently dropped (which used to fall through to pulling all seven).

Pricing

Pay-per-result: you are charged per dataset record emitted. A full 7-ISO snapshot is roughly 18,200 records; a single ISO ranges from ~270 (CAISO, NYISO) to ~9,300 (PJM). Set deltaOnly: true on a scheduled run to be billed only for what actually changed, which is typically a few dozen rows. Failed runs emit nothing and bill nothing.

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.