# US Interconnection Queue Tracker - 7 ISO Queues & Deltas API (`malonestar/interconnection-queue-tracker`) Actor Normalize US ISO/RTO generator interconnection queues (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) into one schema and track new, withdrawn, status-change and COD-slip deltas. For renewables developers, land agents, and energy consultants. Keyless. - **URL**: https://apify.com/malonestar/interconnection-queue-tracker.md - **Developed by:** [Kyle Maloney](https://apify.com/malonestar) (community) - **Categories:** Lead generation, Developer tools, Agents - **Stats:** 3 total users, 2 monthly users, 100.0% runs succeeded, 0 bookmarks - **User rating**: No ratings yet ## Pricing from $4.40 / 1,000 results This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events. Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have. Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event ## What's an Apify Actor? Actors are a software tools running on the Apify platform, for all kinds of web data extraction and automation use cases. In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours, and optionally produces a well-defined JSON output, datasets with results, or files in key-value store. In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server. Actors are written with capital "A". ## How to integrate an Actor? If asked about integration, you help developers integrate Actors into their projects. You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready. The best way to integrate Actors is as follows. In JavaScript/TypeScript projects, use official [JavaScript/TypeScript client](https://docs.apify.com/api/client/js/docs.md): ```bash npm install apify-client ``` In Python projects, use official [Python client library](https://docs.apify.com/api/client/python/docs.md): ```bash pip install apify-client ``` In shell scripts, use [Apify CLI](https://docs.apify.com/cli/docs.md): ````bash # MacOS / Linux curl -fsSL https://apify.com/install-cli.sh | bash # Windows irm https://apify.com/install-cli.ps1 | iex ```bash In AI frameworks, you might use the [Apify MCP server](https://docs.apify.com/integrations/mcp.md). If your project is in a different language, use the [REST API](https://docs.apify.com/api/v2.md). For usage examples, see the [API](#api) section below. For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt). # README ## 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 ```json { "isos": ["PJM", "ERCOT", "ISO-NE"], "mode": "snapshot", "maxResults": 5000 } ```` ### Example input — delta (scheduled monitoring) ```json { "isos": ["SPP"], "mode": "delta", "priorKvKey": "spp_last_snapshot" } ``` ### Example input — automatic monitor mode (deltaOnly) ```json { "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. # Actor input Schema ## `isos` (type: `array`): ISO/RTO codes to pull. Leave empty to pull ALL 7 live sources (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) in one run. All 7 are keyless — no account or API key needed for any of them. ## `mode` (type: `string`): snapshot = emit the current normalized queue, automatically annotated with monitor fields (is\_new\_since\_last\_run, status\_changed, previous\_status) vs. the actor's own self-managed KV snapshot, plus synthetic withdrawn and per-ISO iso\_summary rows. delta = legacy manual mode: compare against a prior snapshot YOU supply (priorItems/priorKvKey) and emit only change rows (new / withdrawn / status\_change / cod\_slip). ## `deltaOnly` (type: `boolean`): Snapshot mode only. When true, suppress unchanged queue rows and emit ONLY new/status-changed rows, synthetic withdrawn rows, and one iso\_summary roll-up row per ISO — ideal for a scheduled weekly/daily monitor run that only cares about what changed. When false (default), the full queue is emitted as before, PLUS the same withdrawn/iso\_summary rows as free bonus monitoring signal. ## `priorItems` (type: `array`): Delta mode: the prior run's unified queue items (the array of records this actor produced before). The diff is computed purely against these. Ignored in snapshot mode. ## `priorKvKey` (type: `string`): Delta mode alternative to priorItems: a key in this actor's key-value store holding the prior snapshot. When set, the current snapshot is also SAVED under this key so scheduled runs diff automatically against the previous run. ## `maxResults` (type: `integer`): Maximum number of queue records to fetch across all selected ISOs. ## Actor input object example ```json { "isos": [ "SPP" ], "mode": "snapshot", "deltaOnly": false, "priorItems": [], "maxResults": 100000 } ``` # Actor output Schema ## `results` (type: `string`): Normalized queue records in the default dataset. # API You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup. ## JavaScript example ```javascript import { ApifyClient } from 'apify-client'; // Initialize the ApifyClient with your Apify API token // Replace the '' with your token const client = new ApifyClient({ token: '', }); // Prepare Actor input const input = { "isos": [ "SPP" ] }; // Run the Actor and wait for it to finish const run = await client.actor("malonestar/interconnection-queue-tracker").call(input); // Fetch and print Actor results from the run's dataset (if any) console.log('Results from dataset'); console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`); const { items } = await client.dataset(run.defaultDatasetId).listItems(); items.forEach((item) => { console.dir(item); }); // 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs ``` ## Python example ```python from apify_client import ApifyClient # Initialize the ApifyClient with your Apify API token # Replace '' with your token. client = ApifyClient("") # Prepare the Actor input run_input = { "isos": ["SPP"] } # Run the Actor and wait for it to finish run = client.actor("malonestar/interconnection-queue-tracker").call(run_input=run_input) # Fetch and print Actor results from the run's dataset (if there are any) print("💾 Check your data here: https://console.apify.com/storage/datasets/" + run["defaultDatasetId"]) for item in client.dataset(run["defaultDatasetId"]).iterate_items(): print(item) # 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start ``` ## CLI example ```bash echo '{ "isos": [ "SPP" ] }' | apify call malonestar/interconnection-queue-tracker --silent --output-dataset ``` ## MCP server setup ```json { "mcpServers": { "apify": { "command": "npx", "args": [ "mcp-remote", "https://mcp.apify.com/?tools=malonestar/interconnection-queue-tracker", "--header", "Authorization: Bearer " ] } } } ``` ## OpenAPI specification ```json { "openapi": "3.0.1", "info": { "title": "US Interconnection Queue Tracker - 7 ISO Queues & Deltas API", "description": "Normalize US ISO/RTO generator interconnection queues (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) into one schema and track new, withdrawn, status-change and COD-slip deltas. For renewables developers, land agents, and energy consultants. Keyless.", "version": "1.0", "x-build-id": "7gJitIS35eeV6n341" }, "servers": [ { "url": "https://api.apify.com/v2" } ], "paths": { "/acts/malonestar~interconnection-queue-tracker/run-sync-get-dataset-items": { "post": { "operationId": "run-sync-get-dataset-items-malonestar-interconnection-queue-tracker", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for its completion, and returns Actor's dataset items in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } }, "/acts/malonestar~interconnection-queue-tracker/runs": { "post": { "operationId": "runs-sync-malonestar-interconnection-queue-tracker", "x-openai-isConsequential": false, "summary": "Executes an Actor and returns information about the initiated run in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/runsResponseSchema" } } } } } } }, "/acts/malonestar~interconnection-queue-tracker/run-sync": { "post": { "operationId": "run-sync-malonestar-interconnection-queue-tracker", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for completion, and returns the OUTPUT from Key-value store in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } } }, "components": { "schemas": { "inputSchema": { "type": "object", "properties": { "isos": { "title": "ISOs / RTOs", "type": "array", "description": "ISO/RTO codes to pull. Leave empty to pull ALL 7 live sources (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) in one run. All 7 are keyless — no account or API key needed for any of them.", "default": [], "items": { "type": "string" } }, "mode": { "title": "Mode", "enum": [ "snapshot", "delta" ], "type": "string", "description": "snapshot = emit the current normalized queue, automatically annotated with monitor fields (is_new_since_last_run, status_changed, previous_status) vs. the actor's own self-managed KV snapshot, plus synthetic withdrawn and per-ISO iso_summary rows. delta = legacy manual mode: compare against a prior snapshot YOU supply (priorItems/priorKvKey) and emit only change rows (new / withdrawn / status_change / cod_slip).", "default": "snapshot" }, "deltaOnly": { "title": "Delta only (monitor mode)", "type": "boolean", "description": "Snapshot mode only. When true, suppress unchanged queue rows and emit ONLY new/status-changed rows, synthetic withdrawn rows, and one iso_summary roll-up row per ISO — ideal for a scheduled weekly/daily monitor run that only cares about what changed. When false (default), the full queue is emitted as before, PLUS the same withdrawn/iso_summary rows as free bonus monitoring signal.", "default": false }, "priorItems": { "title": "Prior items (delta mode)", "type": "array", "description": "Delta mode: the prior run's unified queue items (the array of records this actor produced before). The diff is computed purely against these. Ignored in snapshot mode.", "default": [] }, "priorKvKey": { "title": "Prior snapshot key (delta mode)", "type": "string", "description": "Delta mode alternative to priorItems: a key in this actor's key-value store holding the prior snapshot. When set, the current snapshot is also SAVED under this key so scheduled runs diff automatically against the previous run." }, "maxResults": { "title": "Max results", "minimum": 1, "maximum": 500000, "type": "integer", "description": "Maximum number of queue records to fetch across all selected ISOs.", "default": 100000 } } }, "runsResponseSchema": { "type": "object", "properties": { "data": { "type": "object", "properties": { "id": { "type": "string" }, "actId": { "type": "string" }, "userId": { "type": "string" }, "startedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "finishedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "status": { "type": "string", "example": "READY" }, "meta": { "type": "object", "properties": { "origin": { "type": "string", "example": "API" }, "userAgent": { "type": "string" } } }, "stats": { "type": "object", "properties": { "inputBodyLen": { "type": "integer", "example": 2000 }, "rebootCount": { "type": "integer", "example": 0 }, "restartCount": { "type": "integer", "example": 0 }, "resurrectCount": { "type": "integer", "example": 0 }, "computeUnits": { "type": "integer", "example": 0 } } }, "options": { "type": "object", "properties": { "build": { "type": "string", "example": "latest" }, "timeoutSecs": { "type": "integer", "example": 300 }, "memoryMbytes": { "type": "integer", "example": 1024 }, "diskMbytes": { "type": "integer", "example": 2048 } } }, "buildId": { "type": "string" }, "defaultKeyValueStoreId": { "type": "string" }, "defaultDatasetId": { "type": "string" }, "defaultRequestQueueId": { "type": "string" }, "buildNumber": { "type": "string", "example": "1.0.0" }, "containerUrl": { "type": "string" }, "usage": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "integer", "example": 1 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } }, "usageTotalUsd": { "type": "number", "example": 0.00005 }, "usageUsd": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "number", "example": 0.00005 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } } } } } } } } } ```