Utility interconnect queues are the longest lead-time item in any distributed solar or storage project — routinely stretching 18 to 36 months across high-demand CAISO and PJM territories. For engineers building DER project management tools, that queue is not just a business problem; it's a data access problem. The application needs to know queue position, estimated study completion dates, capacity headroom at the relevant point of interconnection (POI), and whether a project is subject to a Cluster Study or the newer Independent Study track that FERC Order 2023 established.
This guide covers what interconnect queue data actually is, where it comes from, how utilities currently expose it (spoiler: mostly PDFs and spreadsheets), and how you can query it programmatically via Derapi's /v1/ders/interconnect endpoint family.
What the Interconnect Queue Actually Contains
Each ISO and investor-owned utility (IOU) maintains a queue of generation and storage projects seeking permission to connect to the transmission or distribution grid. The data in that queue is standardized by FERC Order 2003 (transmission-level) and by state-level DER interconnect tariffs for distribution-level projects, but "standardized" in this context means roughly the same fields, not the same format or access method.
For a given queue entry, you typically find:
- Queue position number — the sequential ID assigned when an application is received
- Project name and county/state
- Technology type — PV, BESS, wind, hybrid, etc.
- MW capacity — requested nameplate AC/DC
- POI (point of interconnection) — the substation or distribution feeder being studied
- Study stage — feasibility, system impact, facilities study, or agreement execution
- Status — active, withdrawn, suspended, or completed
- Interconnection agreement date (if executed)
What the queue does not reliably contain, and what developers often need, is the actual available capacity headroom at the POI, upgrade cost estimates, or reasons for withdrawal. Those details live in study reports — separate documents, inconsistently published.
How Utilities Currently Expose This Data (and Why It's Painful)
The typical utility queue publication workflow looks like this: a spreadsheet, updated weekly or monthly, posted to a portal page behind a CAPTCHA or login. CAISO's GIQUEUE portal and PJM's Queue Data Access tool are among the more developer-friendly implementations — they have download functions, though not proper REST APIs. Many IOUs in the Southeast or Mountain West publish a static Excel file linked from a PDF filing. Some utilities update on a quarterly cadence.
For an engineering team building a site-screening tool — the kind that takes a candidate address, looks up the nearest substation, checks queue depth and capacity, and returns a go/no-go signal — this means either writing a scraper that breaks on every portal update or hiring someone to do manual data pulls. Neither option scales to the volume of sites that a growing solar EPC or storage developer needs to evaluate.
Consider a scenario common among Pacific Northwest solar developers in 2024: an EPC team evaluating 40–60 candidate commercial rooftop sites per quarter wanted to auto-screen each site against PacifiCorp's distribution interconnect queue before allocating engineering resources. The queue data lived in a spreadsheet on PacifiCorp's website, updated roughly monthly, with no changelog and no API. Manual pulls by the development coordinator took 2–4 hours per update cycle. Every time the spreadsheet format changed — which happened roughly twice per year — the ETL script broke.
The Derapi Interconnect Endpoints
Derapi normalizes this fragmented landscape into three queryable endpoints:
GET /v1/ders/interconnect?zip={zip}&utility={utility_id}
GET /v1/ders/interconnect/queue/{queue_id}
GET /v1/ders/interconnect/capacity?poi={poi_id}&technology=solarThe first endpoint returns queue entries near a ZIP code, filtered by utility territory. The response includes queue position, study stage, MW requested, and a headroom_mw field that represents Derapi's estimate of available capacity at the distribution substation serving that ZIP — derived from the most recent capacity release data and normalized across utility reporting formats.
The second endpoint allows direct lookup of a known queue entry by ID. Useful when your application is tracking a specific project through its study milestones. The response includes a last_status_change timestamp and a study_completion_estimate range (lower and upper bound in days from today, based on the utility's published study timelines and current backlog).
The third endpoint is the capacity query: given a specific POI identifier (substation name or Derapi's internal poi_id), return the available headroom by technology class. This is the highest-value query for site screening.
IEEE 1547 and What It Means for Your Query Parameters
IEEE 1547-2018 is the standard that governs how DERs — solar inverters, battery systems, fuel cells — must behave when connected to the distribution grid. For developers building interconnect-aware applications, the relevant parts are the voltage and frequency ride-through requirements and the reactive power capability parameters that utilities use to classify interconnection complexity.
Derapi's interconnect response includes a category field aligned with IEEE 1547-2018's Category I/II/III classification. Category I is the lowest requirement (typical small residential systems under 30 kW). Category II applies to most commercial-scale DERs. Category III is for systems that need to actively support grid voltage and frequency during disturbances. The category affects the study track your project will be assigned to, and therefore the expected timeline.
When querying the capacity endpoint, you can pass category=2 to filter for headroom available to Category II DERs specifically, rather than total remaining capacity. This is a meaningful distinction: a substation might show 5 MW total headroom but only 2 MW available to new Category II or III projects because earlier projects in the queue are already occupying the protection system upgrade budget.
FERC Order 2023 and the Independent Study Track
FERC Order 2023, finalized in mid-2023 and now being phased in across ISOs, is restructuring how bulk transmission interconnection works. The core change is replacing the serial cluster study model — where one project's study delays cascade to every downstream project in the same cluster — with a largely independent study track for smaller projects under 20 MW AC.
We're not saying FERC Order 2023 solves the interconnect queue backlog; the distribution-level DER queue is primarily regulated at the state level and is outside FERC's direct jurisdiction for most residential and small commercial projects. The Order affects bulk transmission interconnection. But it does signal the direction of regulatory travel: toward more transparent, parallel study processes. Several state PUCs are watching Order 2023 implementation for lessons applicable to distribution-level reform.
Derapi's study_track field in the queue response reflects whether a project is in a cluster or independent study track where that data is available from the ISO or utility. For utilities that don't publish this distinction, the field returns null with a data_available: false flag so your application handles missing data explicitly rather than assuming a default.
Handling Stale Data and Capacity Estimates
One thing worth being direct about: queue data has inherent latency. Even Derapi's normalized queue is working from source data that utilities update weekly or monthly. For time-sensitive project decisions — like whether to sign a land lease before the queue position expires — your application should surface the source_updated_at timestamp prominently and design your UX so users aren't making irreversible decisions based on data that might be 30 days old.
The headroom_mw field is an estimate, not a utility guarantee. It's derived from the utility's published feeder capacity reports combined with the aggregate MW of active queue entries. This is useful for site screening — quickly eliminating substations that are clearly oversubscribed — but it's not a substitute for a formal pre-application report (PAR) from the utility, which is the authoritative capacity assessment for any project moving toward an actual interconnection application.
Your application should treat Derapi's capacity data as a first-pass filter. Query it to reduce a list of 60 candidate sites to 8 worth pursuing. Then proceed to the utility PAR process for those 8. That workflow — bulk screening via API, precise validation via utility process — is where the time savings compound.
Querying by FERC Zone vs. ZIP Code
For applications operating at regional or portfolio scale, querying by ZIP code is too granular. Derapi supports querying by FERC pricing zone (e.g., zone=COMED for the ComEd zone in PJM, or zone=NP15 for CAISO's northern pricing zone) or by utility territory identifier. This lets a portfolio developer pull all queue entries across their target geography in a single request and build a capacity heat map rather than doing point-by-point lookups.
The zone-level query returns aggregate statistics — total MW in queue, withdrawn MW over the past 12 months, estimated study completion backlog in days — along with the individual queue entries. The aggregate stats are particularly useful for a developer doing a high-level market assessment: is NP15 a viable territory for new projects this year, or is the queue so congested that no new projects will get through a system impact study before 2027?
Building this query into your application's market intelligence layer — running it quarterly, storing the results, and comparing capacity trends over time — gives your team a data-driven view of which territories are opening up and which are closing. That's a workflow that used to require a consultant report. With programmatic access, it becomes a background job.