Skip to main content
A collection is a saved configuration that defines which data points to pull from the Fordje platform. Think of it as a reusable template — you define the set of questions once, then run it against any group of AHJs on demand. Collections bundle two things into a named, reusable package:
  • Data point type IDs — the specific regulatory questions you want answered (e.g., “Is a permit required?”, “What is the minimum insulation R-value?”)
  • Category IDs — the regulatory topics the data points belong to (e.g., Permitting, Inspections, Building Standards)
You create collections in the Fordje platform and access them read-only through the API. This separation keeps your integration simple — your code never needs to manage collection definitions, just execute them.

The workflow

Collections follow a define-once, run-anywhere pattern:
  1. Define a collection in the Fordje platform. Pick the data point types and categories you care about, give it a name and description. For example, you might create a “Permitting Requirements” collection that includes data point types for permit applications, fee schedules, and turnaround times across the Permitting category.
  2. Execute the collection via the API. Pass in a set of AHJ IDs and the API returns only the data points that match the collection’s filters. You can run the same collection against different AHJs each time — new project in a new city, same collection, fresh results.
  3. Optionally export as CSV. If your downstream tools (spreadsheets, project management systems, compliance trackers) need a flat file, you can export the collection results as CSV directly from the API.
Collections are scoped to your organization. You can only see and execute collections that belong to your org, and results are further filtered to AHJs in your subscription. See AHJ access control for details.

When to use collections vs ad-hoc queries

Both approaches give you access to the same underlying data. The difference is in how you specify what you want. Use collections when:
  • You pull the same set of data points regularly — every new project needs the same permit data, every quarterly audit checks the same compliance fields
  • Multiple team members or systems need to run the same query — the collection acts as a shared definition
  • You want to keep your API calls consistent and avoid drift between integrations
Use ad-hoc queries when:
  • You are doing exploratory work — browsing what data is available for a new jurisdiction
  • You need a one-off lookup that does not fit an existing collection
  • You are prototyping and the set of data points you need is still changing
Start with ad-hoc queries on GET /v1/data-points to explore what is available. Once you know which data point types and categories you need repeatedly, create a collection in the Fordje platform and switch your integration to use it.

Working with collections

List your collections

To see all collections your organization has created, call the list endpoint:
The data_point_type_ids and category_ids fields tell you exactly what filters the collection applies. You can cross-reference these with the reference data endpoints — GET /v1/data-points/types and GET /v1/categories — to see their human-readable names.

Execute a collection

To run a collection against a set of AHJs, call the data endpoint with the AHJ IDs you want to query:
The response contains the matching published data point values, each tied to its AHJ and data point type. If any of the AHJ IDs you pass are outside your subscription, you will still get results for the ones you have access to, with a warnings array listing the excluded IDs.

Target by geoID instead of AHJ IDs

ahj_ids is optional. As an alternative, pass geoids — a comma-separated list of Census GEOIDs — and the API resolves them to AHJs for you. Provide exactly one of ahj_ids or geoids:
GeoIDs are case-sensitive strings with significant leading zeros (06001, not 6001). Send them as-is — do not strip leading zeros.
Rules: When some geoIDs fail to resolve, the response stays 200 and reports them in the warnings array alongside any access exclusions:

Run a collection for a single geoID

To run a collection against one jurisdiction by geoID, use the /v1/geoid/{geoid} namespace. The response shape is identical to GET /v1/collections/{id}/data, scoped to that single AHJ, and it inherits the page/page_size params:
An unknown geoID returns 404; a resolved AHJ outside your subscription returns 403.

Export as CSV

For workflows that need flat files, you can export a collection’s results directly as CSV:
The response is a CSV file with a Content-Type: text/csv header. The filename in the Content-Disposition header is based on the collection name, so saving with -o gives you a clean local file for import into spreadsheets or other tools.
CSV exports apply the same AHJ access controls as the data endpoint. You only get data for jurisdictions in your subscription.
CSV export accepts the same geoids alternative to ahj_ids (exactly one of the two), and a single-geoID export is available under the geoID namespace:
CSV export does not return a JSON body, so it cannot surface partial warnings — geoIDs that do not resolve are silently skipped. If every supplied geoID fails to resolve, the export fails with 422 instead. To see exactly which geoIDs resolved, call the /data endpoint first.

Next steps

List collections

Full API reference for GET /v1/collections — list your organization’s saved collections.

Execute a collection

Full API reference for GET /v1/collections/{id}/data — run a collection against AHJs.