Skip to main content
GET
Returns the version of the underlying geographic dataset currently live behind the API — which upstream release it was exported from, when that release was imported, and a record-count snapshot taken at import time.
Availability: All plans (Community and above) — no tier restriction. The request still counts toward your daily/monthly usage quota like any other endpoint.

Response headers on every request

Two of the fields above are also stamped as headers on every /v1/* response, not just this endpoint — so you can track the live data version without an extra request:
This metadata is cached, so it can trail a fresh import. This route reads through a 5-minute-TTL cache backed by Redis, so right after an import it can report the previous release for up to about 5 minutes while the new data is already being served. The headers are stamped from an in-memory copy that refreshes every 30 seconds on top of that same cache, so they can trail the imported data by about 5.5 minutes — a deliberate tradeoff so stamping them never adds latency or a new failure mode to every request. Both catch up on their own; no action is needed on your side.X-Request-ID is always present. The two X-CSC-Data-* headers are omitted until the in-memory copy has warmed after a server restart. All three appear on error responses too, because they’re set before routing rather than per endpoint — see Errors & Rate Limits.

npm package parity

The @countrystatecity/countries and @countrystatecity/countries-browser npm packages ship a getDataVersion() loader with the same dataVersion/sourceRelease/updatedAt fields, read from a small bundled version.json instead of a network call. See npm Packages for usage.
Compare sourceRelease, not dataVersion. Both sides build dataVersion from the same release tag, but they append different dates: the npm package uses the date the release was published, while the API uses the date that release was imported. An import lands after the release is published, so the two strings usually differ by a day or more even when both sides hold exactly the same data. sourceRelease is the same string on both sides, which makes it the reliable parity key.For example, the same v3.2-export.7 release can read as v3.2-export.7-2026.07.29 in the package and v3.2-export.7-2026.07.30 from the API.
The package’s recordCounts is also narrower than the API’s: countries/states/cities only, no regions/subregions.

Errors & Rate Limits

The status/message envelope used by the 503 response above, plus usage limits by tier.

npm Packages

Get the same version info without a network call via getDataVersion().

Authorizations

X-CSCAPI-KEY
string
header
required

API key for authentication. Get your free key at app.countrystatecity.in.

Response

Current data release

dataVersion
string
required

<source-release>-<YYYY.MM.DD>; the date is when the release was imported into the API. Same value as the X-CSC-Data-Version header.

Example:

"v3.2-export.7-2026.07.30"

sourceRelease
string
required

Upstream release tag. Compare this, not dataVersion, to check parity with the npm packages.

Example:

"v3.2-export.7"

updatedAt
string<date-time>
required

When the release was imported (UTC)

Example:

"2026-07-30T09:01:18.000Z"

recordCounts
object
required

Row counts snapshotted at import time