Skip to main content
Every piece of regulatory data in Fordje is tied to an AHJ — an Authority Having Jurisdiction. AHJs are the government bodies and utilities that write and enforce building codes, zoning rules, permitting requirements, licensing standards, and utility interconnection policies. There are over 30,000 of them across the United States, and they are the core entity in the Fordje data model. If you are building software that touches construction, energy, permitting, or compliance, AHJs are the reason the rules change from one city to the next. Fordje maps that complexity so you do not have to.

AHJ types

AHJs fall into four categories, each operating at a different level of the regulatory stack: Every AHJ in the API includes a type field so you can distinguish between them programmatically.

Jurisdictional laddering

Building codes do not come from a single source. They layer across multiple levels of government. A construction project in Los Angeles may need to comply with requirements from the City of Los Angeles, Los Angeles County, and the State of California — plus utility interconnection standards from the local utility provider. This layering is called jurisdictional laddering. A city often adopts the state’s base code and then adds its own amendments. A county may impose additional requirements on top of that. The result is a stack of overlapping rules that vary by location. Fordje resolves this behind the scenes. When you pull data points for an AHJ, the values already account for the full chain of parent jurisdictions. You get the complete, resolved answer — not a set of fragments you need to piece together yourself.
You do not need to query multiple AHJ levels and merge the results. Fordje handles jurisdictional laddering internally and returns the effective value for each data point.

Access scoping

Your API key determines which AHJs you can access. Fordje Connect enforces access control based on your organization’s subscription — you only see data for the jurisdictions you are subscribed to.

How it works

Every API request is scoped to your organization’s entitled AHJs:
  1. Your API key identifies your organization
  2. The API resolves which AHJ IDs your subscription includes
  3. Requests are filtered to only return data for those AHJs

Listing endpoints

Endpoints that return lists of data (like GET /v1/ahjs or GET /v1/data-points) automatically scope results to your entitled AHJs. You only see data you have access to.

Specific AHJ requests

When you request a specific AHJ by ID (like GET /v1/ahjs/{id}), the API checks whether that AHJ is in your subscription. If not, you receive a 403 Forbidden response:

Partial access with warnings

When you request multiple AHJs in a bulk endpoint (like GET /v1/data-points?ahj_ids=1,2,999), the API returns data for the AHJs you have access to and includes a warnings array for any excluded IDs:
The API returns a successful response with partial data rather than failing the entire request. Always check the warnings array to detect excluded AHJs.

Full denial

If all requested AHJs are outside your subscription, the API returns a 403 rather than an empty success response.

Endpoint access behavior

Working with AHJs

List your AHJs

To see which AHJs your organization has access to, call the list endpoint. You can filter by state to narrow results:

Get detail for a single AHJ

To retrieve full detail for a specific AHJ, pass its integer ID:
The detail response includes geographic and demographic fields like county, population, and lat/lon that are not present in the list view. Both list and detail responses also carry geoid — the jurisdiction’s Census GEOID (FIPS code) — which can be null for AHJs without a mapped geography (such as utilities).
AHJ IDs are integers, not UUIDs. Make sure your integration stores and passes them as integer values.

Looking up AHJs by geoID

Every AHJ tied to a U.S. geography carries a geoid — its Census GEOID (a FIPS-based identifier). County geoIDs are 5 characters, Census places are 7, and townships are 10. If you already work with Census or TIGER/Line data, the geoid lets you cross-reference Fordje AHJs without ever touching Fordje’s internal integer IDs. Don’t have a GEOID handy? Look one up by address or place name with the U.S. Census Bureau Geocoder or browse the TIGER/Line GEOID reference. You can also get an AHJ’s geoid directly from any /v1/ahjs or /v1/ahjs/{id} response.
GeoIDs are case-sensitive strings with significant leading zeros. 06001 (Alameda County, CA) is not the same as 6001. Always store and pass them as strings — never as integers — or the leading zeros will be lost and the lookup will fail.

Resolve a geoID to an AHJ

Pass the geoID on the /v1/geoid/{geoid} path. The response is identical to GET /v1/ahjs/{ahj_id} — full AHJ detail, including the geoid itself.

Resolution semantics

A geoID is intended to be 1:1 with an AHJ. In the rare case the same geoID maps to more than one AHJ, the API returns the lowest-numbered AHJ ID.
You can also run a saved collection against a single geoID — see running a collection for one geoID.

Next steps

List AHJs

Full API reference for GET /v1/ahjs — query parameters, response fields, and filtering.

Get AHJ detail

Full API reference for GET /v1/ahjs/{ahj_id} — all response fields including geographic data.