# US Interconnection Queue Tracker (`jyinnovation/us-interconnection-queue-tracker`) Actor

Track US power-grid interconnection queues (CAISO, ERCOT, MISO, SPP, NYISO, ISO-NE) in one normalized schema. Get only what changed since your last run: new projects, withdrawals, status moves, COD slips and capacity changes. Filter by state, technology, size and queue date.

- **URL**: https://apify.com/jyinnovation/us-interconnection-queue-tracker.md
- **Developed by:** [JYInnovation](https://apify.com/jyinnovation) (community)
- **Stats:** 3 total users, 2 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $5.00 / 1,000 queue changes

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/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
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.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## 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.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## US Interconnection Queue Tracker: CAISO & ERCOT Queue Data and Change Alerts

**Download US power-grid interconnection queues as one clean table, or get only what changed since your last run: new projects, withdrawals, slipped in-service dates and capacity changes.** Schedule it daily or weekly and it becomes an alert feed for solar, storage, wind, gas and large-load projects across California (CAISO) and Texas (ERCOT), the two largest US queues for solar, storage and large loads, with no spreadsheets to open and compare by hand.

### Who it is for

- **Renewable and storage developers** watching competing projects, withdrawals and queue positions near a site.
- **Data-center and large-load site selection teams** looking for where capacity is being requested, withdrawn or delayed.
- **Energy analysts and investors** tracking pipeline attrition, completion-date slippage and technology mix.
- **Consultants and land agents** who need a weekly "what changed in the queue" digest for clients.

### What you get

One normalized schema for all supported grid operators (ISOs/RTOs). Fields an ISO does not publish are `null`.

| Field | Description |
|---|---|
| `iso` | `CAISO` or `ERCOT` |
| `queue_id` | The ISO's queue / project identifier |
| `project_name`, `interconnecting_entity` | Project name and developer or interconnecting entity, where published |
| `state`, `county` | Location |
| `interconnection_location`, `transmission_owner` | Point of interconnection and transmission owner, where published |
| `generation_type` | Technology / fuel as published (for example Solar, Battery Storage, Wind, Gas, Load) |
| `capacity_mw`, `summer_capacity_mw`, `winter_capacity_mw` | Requested capacity in MW |
| `queue_date` | Date the request entered the queue |
| `status` | Status as published (for example Active, Withdrawn, Completed) |
| `proposed_completion_date`, `actual_completion_date` | Proposed and actual in-service dates |
| `withdrawn_date`, `withdrawal_comment` | Withdrawal details, where published |
| `record_key` | Stable key (`ISO:queue_id`) used for change detection |
| `raw` | Optional: every extra column the ISO publishes (turn on **Include ISO-specific raw fields**) |

Dates are `YYYY-MM-DD`. Status labels and technology names follow each ISO's own publication and are only partly standardized.

### Two modes

**Full snapshot.** One row per queue project, for every ISO you select, after your filters.

**Changes since last run (default).** One row per detected change, with the project's details plus what changed.

- **The first run per ISO is the baseline.** It saves the current queue to your own storage and outputs nothing (and charges nothing). Changes are reported from the second run on.
- Each later run compares the new download with your saved baseline, then replaces the baseline.

| `change_type` | Meaning |
|---|---|
| `new_project` | A queue ID that was not in the previous download |
| `withdrawn` | Status changed to a withdrawn status |
| `completed` | Status changed to completed / in service / operational |
| `status_changed` | Any other status change |
| `completion_date_changed` | Proposed completion date moved (later or earlier) |
| `capacity_changed` | Capacity (MW) changed |
| `generation_type_changed`, `interconnection_location_changed`, `project_name_changed` | Those fields changed |
| `removed_from_publication` | A project that was in the previous download is no longer published (shows the project details saved in your baseline) |

Change rows add `field`, `old_value`, `new_value` and `change_detected_on`.

### Filters

All optional, applied to the output (the baseline always stores the full queue, so changing a filter never loses history):

- **States** (for example `TX`, `CA`)
- **Technology contains** (case-insensitive words such as `Solar`, `Battery`, `Storage`, `Wind`, `Gas`, `Load`)
- **Status** (for example `Active`, `Withdrawn`, `Completed`)
- **Minimum and maximum capacity (MW)**
- **Queue date on or after**

In changes mode the filters apply to the project as it is now (or its last saved values for `removed_from_publication`).

### Sample output

Illustrative example only. Project names, IDs and values below are made up and do not describe a real project.

Changes mode (a slipped in-service date):

```json
{
  "iso": "ERCOT",
  "queue_id": "EX-0001",
  "project_name": "Example Solar Storage",
  "interconnecting_entity": "Example Energy LLC",
  "county": "Pecos",
  "state": "TX",
  "interconnection_location": "Example 345 kV Substation",
  "transmission_owner": null,
  "generation_type": "Solar",
  "capacity_mw": 200.0,
  "queue_date": "2024-01-05",
  "status": "Active",
  "proposed_completion_date": "2028-01-01",
  "record_key": "ERCOT:EX-0001",
  "change_detected_on": "2026-10-05",
  "change_type": "completion_date_changed",
  "field": "proposed_completion_date",
  "old_value": "2027-06-01",
  "new_value": "2028-01-01"
}
```

Snapshot mode returns the same project fields without the change columns.

A run summary (projects per ISO, changes found, items output, and any ISO that failed) is saved as `OUTPUT` in the run's key-value store. If one ISO's site is down or changes its format, the other ISOs still run and the failed one is listed in the summary.

### How to use

1. Choose **Full snapshot** (the default: the current queue, filtered) or **Changes since last run** (an alert feed; the first run only saves a baseline).
2. Select the grid operators and, optionally, filters.
3. Run it once. In changes mode this creates the baseline.
4. **Schedule it** (daily or weekly) and connect the dataset to email, Slack, Google Sheets or a webhook with Apify integrations.

**Scheduling tip:** use one schedule per **Baseline store name**. The baseline lives in a named key-value store in your own Apify account (default `interconnection-queue-tracker`). If two schedules share a store name they consume each other's baseline and one of them will miss changes. Use a different name for each separate watchlist, for example `queue-watch-texas-storage`. ISOs refresh their files on their own schedules (some daily, some weekly or monthly), so running more often than daily rarely finds more.

### Pricing

Pay per event, so you only pay for rows you receive:

| Event | When it is charged | Price |
|---|---|---|
| `queue-row` | One project row in **Full snapshot** mode (after filters) | **$0.001** per row ($1.00 per 1,000) |
| `queue-change` | One detected change in **Changes** mode (after filters) | **$0.005** per change ($5.00 per 1,000) |

The baseline run in changes mode charges no `queue-row` or `queue-change` events. A changes run that finds nothing costs nothing beyond the platform's standard run start charge, if any. Filters reduce what you pay for. Set a **maximum charge per run** to cap your spend.

If a run reaches your maximum charge the Actor stops outputting for that run and keeps the previous baseline for that ISO, so the undelivered changes are reported again on the next run (some already-delivered changes may repeat). Set a generous cap for scheduled runs.

### Data sources, attribution and disclaimer

Each run downloads the current public interconnection-queue publication from each ISO/RTO website, using the open-source [gridstatus](https://github.com/gridstatus/gridstatus) library (BSD-3-Clause):

| ISO | Source |
|---|---|
| CAISO | California ISO public queue report (`PublicQueueReport.xlsx`) |
| ERCOT | ERCOT GIS report, published through the ERCOT Market Information System |

Attribution: queue data is published by the California ISO (CAISO) and the Electric Reliability Council of Texas (ERCOT). Please credit the California ISO as the source of CAISO data.

Disclaimer: this Actor is an independent tool, is not affiliated with, endorsed by or sponsored by any ISO/RTO, and uses their names only to identify the data source. Data is provided "as is" without warranty of accuracy, completeness or timeliness. ISOs revise or reformat their files without notice, and this Actor normalizes field names and status labels on a best-effort basis. ERCOT does not guarantee the accuracy of compilations or analyses built on its data, and neither do we. Always confirm material decisions against the ISO's official queue, tariff and procedures. ISO names and logos are trademarks of their owners. You are responsible for complying with each ISO's own terms of use for any further use or redistribution of the data.

### Limitations

- **Other grid operators (MISO, SPP, PJM, NYISO, ISO-NE) are not included.** Their website terms restrict or don't clearly allow commercial redistribution. If you need one of them, open an issue: we'll add it once the operator confirms reuse in writing.
- **Upstream format changes.** ISOs move, rename or reformat their files without notice. When that happens that ISO is reported as `failed` in the run summary until the Actor is updated; the other ISOs are unaffected.
- **Different ISOs, different fields.** Some ISOs do not publish developer, county, withdrawal dates or queue dates for every project. Fields that are not published are `null`.
- **Not every project is in a queue.** Distributed generation and projects handled by utilities rather than the ISO may not appear.
- **Update frequency is set by the ISO**, not by this Actor.
- Change detection compares the fields listed above. Edits to other fields (for example a developer rename) are not reported.

### FAQ

**Why did my first changes-mode run return nothing?**
That run created your baseline. It is working as intended and costs nothing for rows. You get changes from the second run on.

**Can I get the full current queue once and then only changes?**
Yes. Run once in **Full snapshot** mode to get the full table, then run in **Changes** mode: the first changes run creates the baseline and later runs report differences.

**How do I get alerts in Slack or email?**
Schedule the Actor, then add an Apify integration or webhook on the schedule's runs that sends the dataset items to Slack, email, Google Sheets, Make or Zapier.

**Is the data real time?**
No. It is as fresh as each ISO's own publication, which ranges from daily to monthly, and it is downloaded when your run starts.

**One ISO failed. Do I still get the others?**
Yes. Each ISO runs separately. The failed ISO is listed with an error in the `OUTPUT` summary, and its baseline is left untouched so nothing is lost for the next run.

**I need an ISO or a field that is missing.**
Open an issue on the Actor page with the ISO and the field you need.

### Support

Questions or a missing field? Open an issue on the Actor page. Replies are written, usually within a day.

Built by **JYInnovation**.

# Actor input Schema

## `mode` (type: `string`):

<b>changes</b>: output only what changed since your previous run (new projects, withdrawals, status, completion-date and capacity changes). The first run per ISO just saves a baseline. Schedule it daily or weekly.<br><b>snapshot</b>: output the full current queue (one row per project).

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

Which public queues to download. Currently CAISO (California) and ERCOT (Texas).

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

Only output projects in these states, e.g. TX, CA. Leave empty for all.

## `generationTypes` (type: `array`):

Keep projects whose technology / generation type contains any of these words (case-insensitive), e.g. Solar, Battery, Storage, Wind, Gas, Load.

## `statuses` (type: `array`):

Keep only these statuses, e.g. Active, Withdrawn, Completed.

## `minCapacityMw` (type: `integer`):

Optional.

## `maxCapacityMw` (type: `integer`):

Optional.

## `queueDateFrom` (type: `string`):

Optional, YYYY-MM-DD.

## `includeRawFields` (type: `boolean`):

Adds every extra column the ISO publishes under 'raw'.

## `stateStoreName` (type: `string`):

Named key-value store that keeps your previous snapshot. Use different names to track separate watchlists.

## Actor input object example

```json
{
  "mode": "snapshot",
  "isos": [
    "CAISO",
    "ERCOT"
  ],
  "states": [
    "TX"
  ],
  "generationTypes": [
    "Battery",
    "Storage"
  ],
  "includeRawFields": false,
  "stateStoreName": "interconnection-queue-tracker"
}
```

# Actor output Schema

## `items` (type: `string`):

No description

## `summary` (type: `string`):

No description

# 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 = {
    "mode": "snapshot",
    "states": [
        "TX"
    ],
    "generationTypes": [
        "Battery",
        "Storage"
    ]
};

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

# Prepare the Actor input
run_input = {
    "mode": "snapshot",
    "states": ["TX"],
    "generationTypes": [
        "Battery",
        "Storage",
    ],
}

# Run the Actor and wait for it to finish
run = client.actor("jyinnovation/us-interconnection-queue-tracker").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "mode": "snapshot",
  "states": [
    "TX"
  ],
  "generationTypes": [
    "Battery",
    "Storage"
  ]
}' |
apify call jyinnovation/us-interconnection-queue-tracker --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,jyinnovation/us-interconnection-queue-tracker"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/6f2LhfYnQpIubfLHz/builds/FYbEM8rswqUtC6sUx/openapi.json