# Interconnection Queue Monitor (`springstea/interconnection-queue-monitor`) Actor

Monitors US grid interconnection queues (CAISO, PJM, MISO) and reports every project change as structured data: new applications, withdrawals, capacity and COD changes, study-phase progress. Filter by fuel, state and size.

- **URL**: https://apify.com/springstea/interconnection-queue-monitor.md
- **Developed by:** [Kasım Genç](https://apify.com/springstea) (community)
- **Categories:** Business, Automation, Lead generation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $5.00 / 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.

Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
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.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — 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

## Interconnection Queue Monitor

Monitors US grid **interconnection queues** — the official waiting lists of every power plant and battery project seeking to connect to the grid — and reports each change as structured data:

- "A new 200 MW battery project entered the PJM queue in Ohio."
- "This solar project moved from Phase 1 to GIA — it's getting real."
- "Competitor X's project was withdrawn." / "Project Y just reached commercial operation."
- "The proposed COD slipped two years."

**Coverage:** CAISO (California), PJM (13 Mid-Atlantic/Midwest states), MISO (15 Central US states) — together roughly 15,000 tracked queue positions. Sources are the ISOs' official public queue reports. (ERCOT, NYISO, ISO-NE are on the roadmap; their downloads sit behind aggressive bot protection.)

### Who uses this

- **Project developers** — track competing projects near your POI, spot withdrawals that free up headroom.
- **Land agents & site originators** — new queue entries reveal who is developing where, months before permits.
- **Equipment vendors & EPCs** — projects advancing to later study phases are buying signals.
- **Investors & analysts** — queue trends by fuel/region without manually diffing spreadsheets.

### How it works

Each run downloads the current queue from every selected ISO, normalizes projects into a common shape, and diffs them against the snapshot from the previous run (kept in a named key-value store). Only changes matching your filters are output. Schedule it **daily or weekly** for a continuous feed.

- The first run per ISO establishes the baseline (silent by default — see `emitBaselineRecords`).
- If an ISO's download fails, its snapshot stays untouched and the other ISOs still process — a flaky source can't produce phantom changes.
- Withdrawn-to-withdrawn noise is suppressed unless you opt in (`includeWithdrawn`).

### Input

```json
{
    "isos": ["CAISO", "PJM", "MISO"],
    "fuels": ["solar", "battery", "hybrid"],
    "states": ["CA", "OH", "IL"],
    "minCapacityMW": 50,
    "emitBaselineRecords": false
}
```

| Field | Type | Description |
|---|---|---|
| `isos` \* | `string[]` | `CAISO`, `PJM`, `MISO` (any subset). |
| `fuels` | `string[]` | `solar`, `wind`, `battery`, `hybrid` (co-located, e.g. solar+storage), `gas`, `nuclear`, `hydro`, `geothermal`, `biomass`, `coal`, `oil`, `other`. Empty = all. |
| `states` | `string[]` | 2-letter codes. Empty = all. |
| `minCapacityMW` | `integer` | Minimum project size. Default 0. |
| `includeWithdrawn` | `boolean` | Also track projects that are already withdrawn. Transitions *into* withdrawn are always reported. Default `false`. |
| `emitBaselineRecords` | `boolean` | Push all matching projects as `baseline` on the first run. Queues are large (PJM ~9,000 rows) — leave off unless you want the full current picture. Default `false`. |
| `snapshotStoreName` | `string` | Named KV store for snapshots between runs. |

### Output

One dataset record per changed project, largest capacity first:

```json
{
    "iso": "CAISO",
    "queueId": "CAISO-17",
    "projectName": "SONORAN 2",
    "state": "CA",
    "county": "RIVERSIDE",
    "utility": "SCE",
    "poi": "Colorado River Substation 230 kV",
    "fuel": "hybrid",
    "fuelRaw": "Photovoltaic + Battery",
    "capacityMW": 400,
    "status": "withdrawn",
    "previousStatus": "active",
    "statusRaw": "WITHDRAWN",
    "studyPhase": "IA: Executed",
    "queueDate": "2019-04-10",
    "proposedCOD": "2027-06-01",
    "changeType": "project_withdrawn",
    "changes": [
        { "field": "status", "kind": "status_changed", "old": "active", "new": "withdrawn" }
    ],
    "queueUrl": "https://www.caiso.com/library/public-queue-report",
    "detectedAt": "2026-07-10T15:41:05.892Z",
    "source": "CAISO public interconnection queue"
}
```

#### `changeType` values

| Value | Meaning |
|---|---|
| `baseline` | First run for an ISO — current state of a project (opt-in). |
| `new_project` | New queue entry appeared. |
| `project_withdrawn` | Project left the queue (withdrawn/retracted/canceled). |
| `project_in_service` | Project reached commercial operation. |
| `project_suspended` | Project suspended. |
| `status_changed` | Other status transition. |
| `capacity_changed` | MW figure changed (see `oldCapacityMW`). |
| `cod_changed` | Proposed/actual commercial operation date changed (see `previousCOD`). |
| `phase_changed` | Study phase / interconnection agreement status advanced. |
| `project_updated` | Other material change (POI, name, transmission owner). |
| `removed_from_queue` | Row disappeared from the source report entirely. |

The run summary (per-ISO counts, failures) is stored under the `OUTPUT` key of the default key-value store.

### Data sources & update cadence

| ISO | Source | Typical update |
|---|---|---|
| CAISO | [Public Queue Report (XLSX)](https://www.caiso.com/library/public-queue-report) | ~monthly |
| PJM | [Planning API queue export (XLSX)](https://www.pjm.com/planning/service-requests/serial-service-request-status) | ~daily |
| MISO | [GI Queue API (JSON)](https://www.misoenergy.org/planning/generator-interconnection/GI_Queue/gi-interactive-queue/) | ~weekly |

Daily scheduling is safe — unchanged sources simply produce zero records.

# Actor input Schema

## `isos` (type: `array`):

Which interconnection queues to monitor. Supported: <code>CAISO</code> (California), <code>PJM</code> (Mid-Atlantic/Midwest, 13 states), <code>MISO</code> (Central US, 15 states). ERCOT, NYISO and ISO-NE are on the roadmap (their sources sit behind aggressive bot protection).

## `fuels` (type: `array`):

Only report projects with these fuels. Slugs: <code>solar</code>, <code>wind</code>, <code>battery</code>, <code>hybrid</code> (co-located, e.g. solar+storage), <code>gas</code>, <code>nuclear</code>, <code>hydro</code>, <code>geothermal</code>, <code>biomass</code>, <code>coal</code>, <code>oil</code>, <code>other</code>. Empty = all fuels.

## `states` (type: `array`):

Only report projects in these states (2-letter codes, e.g. <code>TX</code>, <code>CA</code>, <code>IL</code>). Empty = all states.

## `minCapacityMW` (type: `integer`):

Only report projects at or above this size. 0 = no minimum.

## `includeWithdrawn` (type: `boolean`):

Transitions INTO withdrawn status are always reported. Enable this to also include projects that were already withdrawn (baseline records and updates on withdrawn projects).

## `emitBaselineRecords` (type: `boolean`):

On the first run for an ISO there is nothing to compare against. When enabled, every project matching your filters is pushed with changeType <code>baseline</code>. <b>Caution:</b> queues are large (PJM ~9,000, MISO ~3,800 rows) — with no filters this produces thousands of results. Default off.

## `snapshotStoreName` (type: `string`):

Named key-value store keeping per-ISO snapshots between runs.

## `proxyConfiguration` (type: `object`):

Optional proxies for the queue downloads.

## Actor input object example

```json
{
  "isos": [
    "CAISO",
    "PJM",
    "MISO"
  ],
  "fuels": [],
  "states": [],
  "minCapacityMW": 0,
  "includeWithdrawn": false,
  "emitBaselineRecords": false,
  "snapshotStoreName": "interconnection-queue-monitor"
}
```

# 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 '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "isos": [
        "CAISO",
        "PJM",
        "MISO"
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("springstea/interconnection-queue-monitor").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 '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "isos": [
        "CAISO",
        "PJM",
        "MISO",
    ] }

# Run the Actor and wait for it to finish
run = client.actor("springstea/interconnection-queue-monitor").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": [
    "CAISO",
    "PJM",
    "MISO"
  ]
}' |
apify call springstea/interconnection-queue-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "command": "npx",
            "args": [
                "mcp-remote",
                "https://mcp.apify.com/?tools=springstea/interconnection-queue-monitor",
                "--header",
                "Authorization: Bearer <YOUR_API_TOKEN>"
            ]
        }
    }
}

```

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/pajGjFWt9R83LBVPc/builds/yYL2CBnIG2OUltbIq/openapi.json