Jurisdiction Canonicalization
Check is consolidating every resource onto a single canonical jurisdiction code
Check is consolidating every resource onto the single canonical jurisdiction code described in Jurisdictions — fed or a lowercased ISO 3166-2:US region code.
Why
Across Check's APIs, the same idea of a jurisdiction has been represented in several different ways, with identifiers that do not align from one resource to another — opaque jur_ IDs in some places, uppercase abbreviations in others, and a bare ?state= filter elsewhere. That makes it hard to reliably join or roll data up to a jurisdiction across resources.
Standardizing on one canonical code fixes that: a single, human-readable value means the same thing everywhere, so you can group filings, taxes, parameters, and elections by jurisdiction with confidence. It is also the foundation the newer reference resources (Tax and Agency) and future agency-referencing resources are built on.
Impacted resources
The table below maps each legacy jurisdiction representation to its canonical replacement:
| Resource | Legacy representation | Canonical replacement |
|---|---|---|
| Company / employee tax elections | jur_ ID plus an uppercase jurisdiction_abbreviation | jurisdiction code |
| Tax parameters | jurisdiction as a jur_ ID | jurisdiction code |
| Reciprocity elections | jur_ ID plus a non-standard jurisdiction_name | jurisdiction code |
| Applied-for tax params report | bare uppercase string (e.g. "AL") | jurisdiction code |
company_tax_params/{id}/jurisdictions | { id, label } object shape | jurisdiction code |
| Filings | ?state= query filter | ?jurisdiction= query filter |
Workplace.address_state is not changing. It is the state of a physical address (an uppercase USPS code), which is a different concept from a tax jurisdiction.
Tax elections are the most sensitive case: their
jurisdictionis ajur_ID, and many integrations join tax-election data to the tax catalog. If you depend on the legacyjur_IDs or uppercase abbreviations anywhere, flag it to your Check contact so we can sequence your migration.
How the migration rolls out
Wherever possible, these changes are additive — a new canonical field appears alongside the existing one. Where a representation actually changes, Check runs the canonical and legacy fields in parallel and coordinates the cutover with each partner before sunsetting the legacy form. This does not require a new API version. If you maintain an integration against any of the resources above, your Check contact will work with you to schedule the transition.