There are roughly 19,000 authority-having jurisdictions (AHJs) in the United States. Each one sets its own permit requirements for solar installations. Some follow the IEC 60364 or NEC 2020/2023 standards closely. Many add local amendments. Some accept SolarApp+ for expedited permit issuance; most don't. Some require wet-stamped structural calculations for any rooftop system over 5 kW; others process the same system in a day with a simple online form.
For a solar EPC company operating across multiple states, or a software company building a proposal tool for solar contractors, this variation is a genuine engineering problem. It's also a data problem: there's no national registry of AHJ requirements. The data is locked in municipal websites, state solar websites, utility portal pages, and individual phone calls with permit offices.
Derapi's permit endpoint normalizes this fragmented landscape across 2,400+ US jurisdictions. This article explains how the data is structured, what the endpoint returns, and how to build permit-aware workflows on top of it.
What "AHJ Requirements" Actually Means in Practice
When a solar contractor submits a permit application, the AHJ (typically the local building department, occasionally the fire marshal or electrical department) reviews it against a checklist. That checklist varies by jurisdiction, but the common elements are:
- Electrical diagram requirements — single-line diagram (SLD), three-line for larger systems, labeling conventions
- Structural calculations — whether engineered stamped calculations are required, and the basis (wind speed zone, ground snow load, seismic zone)
- Setback requirements — roof access pathways per International Fire Code (IFC) or local amendment
- Interconnection form — whether a separate utility interconnection application is required alongside the building permit
- Inspection stages — rough-in inspection, final inspection, utility witness inspection (some utilities require on-site presence at meter installation)
- SolarApp+ participation — whether the jurisdiction accepts SolarApp+ instant approval
- Fee schedule — flat fee, $/watt, or valuation-based permit fee
A solar design tool needs these requirements before generating the permit package. A proposal tool needs to know whether the jurisdiction is "fast-permit" (a selling point for the contractor) or slow. A project tracking tool needs to know what inspection stages to model in the project timeline.
How the Permit Endpoint Works
The primary query is by ZIP code or latitude/longitude:
GET /v1/permits/ahj?zip=94103&system_size_kw=25&system_type=rooftop_pvThe response identifies the applicable AHJ (which may be a city, county, or special district depending on address), returns the permit requirements object, and flags any known local amendments to NEC or IFC that affect the checklist.
The system_size_kw parameter matters: some AHJs have size-based thresholds where larger systems face additional requirements. A 10 kW residential system in San Jose, CA, may qualify for SolarApp+ instant approval; a 50 kW commercial system at the same address does not. Passing the system size at query time ensures the response reflects the applicable checklist, not a generic default.
The response schema includes:
{
"ahj_id": "CA-SANJOSE-0042",
"ahj_name": "City of San Jose Building Division",
"state": "CA",
"solarapp_plus_eligible": false,
"nec_version": "2020",
"structural_calcs_required": true,
"structural_basis": "ASCE 7-22",
"setback_standard": "IFC_2021_Section_1204",
"setback_pathway_ft": 3,
"utility_interconnect_required_separately": true,
"utility_id": "PG&E",
"inspection_stages": ["rough_in", "final", "utility_meter_set"],
"permit_fee_structure": "valuation_based",
"permit_turnaround_days_typical": 15,
"last_updated": "2025-08-20"
}The Coverage Problem and What Derapi Does About It
No third-party database covers all 19,000 AHJs. Derapi's 2,400+ coverage is weighted toward high-solar-activity jurisdictions — California, Texas, Arizona, Florida, and the Northeast markets — where the majority of solar permit volume concentrates. Coverage in rural counties with very low solar activity is sparser.
We're not claiming Derapi replaces every permit office call. For a jurisdiction outside our coverage, the endpoint returns a coverage_status: "partial" or "not_covered", along with whatever state-level defaults we can provide (state NEC adoption version, state fire code, typical setback requirements based on neighboring jurisdictions) and a link to the AHJ's official website where available.
Building this into your application correctly means designing for the partial-coverage case: when coverage_status is not "full", your UX should indicate that the contractor should verify with the jurisdiction directly. Never present partial coverage data with the same confidence indicator as full coverage data. The downstream risk — a permit rejection due to a local amendment you didn't capture — falls on the contractor, not Derapi.
SolarApp+ Integration: Fast Permit Jurisdictions
SolarApp+ (the national instant solar permit platform, administered by NREL in collaboration with the DOE SunShot-successor programs) allows participating AHJs to issue permits instantly for systems that pass automated code compliance checks. As of late 2025, SolarApp+ participation has grown to over 300 jurisdictions, concentrated in California, Colorado, and several Northeast states.
Derapi's solarapp_plus_eligible field reflects current participation. For applications where speed-to-permit is a sales differentiator — proposals that tell a homeowner "we can pull your permit today" — filtering sites by solarapp_plus_eligible: true is a high-value query. Your proposal tool can flag these sites differently, allowing your sales team to lead with a faster timeline for qualifying systems.
The nuance: SolarApp+ eligibility requires both AHJ participation and system compliance. A system that uses non-listed components or has design features that don't pass SolarApp+'s automated compliance engine will be rejected even in participating jurisdictions. Derapi's solarapp_plus_eligible field tells you about the jurisdiction; your design tool's compliance check is a separate layer.
Fire Code Setbacks: The IFC vs. Local Amendment Problem
One of the most common permit rejection causes for residential and commercial rooftop solar is setback non-compliance. The International Fire Code (IFC) requires access pathways on pitched roofs — typically a 3-foot clear path along the ridge and from the eave to the ridge on one side. Many jurisdictions have adopted local amendments: a smaller setback (e.g., California's AB 2188, which limits AHJs from requiring setbacks greater than the IFC minimum for systems under 10 kW), or a larger setback for multi-family buildings.
The setback_standard and setback_pathway_ft fields in the permit response give your design tool the applicable setback constraint. A well-integrated workflow passes this constraint into the roof polygon layout algorithm, ensuring the design generated for the permit package already respects the setback before the permit is submitted.
Consider an EPC team operating across California's Central Valley and Bay Area markets in 2024. Setback requirements varied from 3 feet (IFC standard) to 18 inches (AB 2188 reduced setback for eligible systems) depending on the jurisdiction and system size. Without programmatic access to these rules, the team's drafters were looking up each jurisdiction manually before each design revision. Querying Derapi's permit endpoint as part of the design-initiation workflow — pulling the setback constraint for the site ZIP — eliminated that lookup and reduced per-project drafting time by one step. The savings compound over the volume of projects an EPC team runs in a quarter.
Keeping Permit Data Fresh
AHJ requirements change. NEC versions are adopted on a rolling basis (most states are on 2020 or 2023; some have local amendments that freeze an older version). Fire codes update every 3 years on the IFC cycle. Local jurisdictions adopt changes at their own pace, with varying lag times.
Each record in Derapi's permit dataset includes a last_updated timestamp. For high-frequency workflows — a design tool processing dozens of permits per day — your application should treat records older than 90 days as potentially stale and surface a "verify with jurisdiction" note for those sites. This is not a data quality failure; it's the reality of a dataset built on top of a fragmented, non-standardized source system. Designing your application to surface data freshness to users is part of building a reliable tool, not a caveat to hide in the documentation.