Skip to main content
Use these endpoints to look up jurisdiction rules when you have structured address components rather than a ZIP code. The engine resolves the most locally specific rule available: if a city-level rule exists, it takes precedence over the county rule, which takes precedence over the state rule. All three endpoints return the same JurisdictionRule shape.

Authentication

All requests require an x-api-key header.

Endpoint variants

Resolve by state

Returns the statewide rounding rule for the given two-letter state code.
string
required
Two-letter U.S. state code. Example: AZ

Resolve by state and county

Returns the rounding rule for the specified county. Falls back to the state rule if no county-level rule exists.
string
required
Two-letter U.S. state code. Example: AZ
string
required
County name. Example: Maricopa

Resolve by state, county, and city

Returns the most specific rounding rule available for the given location. The engine checks for a city-level rule first, then county, then state.
string
required
Two-letter U.S. state code. Example: AZ
string
required
County name. Example: Maricopa
string
required
City name. Example: Phoenix

Response fields

string
The key used to look up this rule in the database. Example: AZ
string
Jurisdiction identifier. Example: US-AZ
string
The level in the hierarchy where the rule was found. One of: federal, state, county, city
string
The rounding algorithm that applies. One of: swedish_rounding, mandatory_round_down, mandatory_round_up, symmetrical_rounding, nearest_nickel, nearest_cent, nearest_dime, none
string
How strictly the rule applies. One of: mandatory, permissive, voluntary, none
string
Legislative status. One of: enacted, pending, proposed, failed, no_legislation
string
The bill or regulation that enacted this rule. Example: AZ HB 2938
string
The date the rule took effect, in ISO 8601 date format.