The API and bulk files provide two paths into the same standardized property record. The better choice depends on how many properties you need, when you need them, and whether your team wants to operate a local copy.
Choose the API for targeted, live requests
Use the API when an application needs one property, a small result set, or a user-defined area at request time. Supported lookup patterns include addresses, coordinates, parcel identifiers, polygons, and field filters. A title-search product might look up a parcel after a user submits an address. A site-selection tool might request every intersecting parcel after a user draws a polygon.
The API removes the need to load a nationwide dataset before the first query. Your application sends a request, receives JSON, and stores only what its workflow needs. It also gives you one endpoint while PropertyLayer handles county-specific source formats behind it.
API usage is metered by returned records. Plan limits and rate limits still matter. A process that repeatedly scans millions of properties will usually be simpler and less expensive against a local bulk copy.
Choose bulk files for complete-area work
Bulk data fits analysis that starts with a whole county, state, or nationwide file. Common examples include warehouse loading, GIS overlays, model inputs, mailing-area selection, exposure analysis, and scheduled portfolio screening.
A bulk purchase gives your team a fixed delivery to inspect, version, and join with internal data. It works well for repeat queries because each pass runs against your own database or GIS. The tradeoff is operational: your team owns ingestion, indexing, storage, and replacement when a new file arrives.
PropertyLayer lists county and state record counts and prices in the coverage directory. Check the county pages before purchase because field presence differs by source.
Use both when the workflow has two speeds
Many systems have a large baseline and a smaller live edge. A bulk file can seed a warehouse or map layer. The API can then handle user lookups, fill a request outside the loaded geography, or retrieve a current record without waiting for the next warehouse job.
This split also helps during product development. Start with the API while query patterns are still changing. Move stable, high-volume scans to bulk files when the query volume and geography justify the extra data operations.
A practical decision test
Ask four questions:
- Does the job begin with a known address or area, or with every property in a geography?
- Will the same records be scanned many times?
- Does the application need a response during a user session?
- Does the team already run a spatial database or warehouse?
If the work begins with a user request and returns a narrow result, start with the API. If it begins with a county or state and repeats locally, start with bulk data. If both descriptions are true, use a bulk baseline and the API for live requests.
Review API pricing, bulk pricing, and the data dictionary before committing to an integration.
For geospatial delivery details, consult the IETF’s GeoJSON standard and the Open Geospatial Consortium’s GeoPackage standard.