oneapiAdministrative units
Localities, towns, communes, counties and regions, with the full administrative hierarchy, official codes and coordinates. The reference set for every address field in your application.
{
"data": [
{ "nume": "Cluj-Napoca", "cod": 54975, "judet": "CJ", "tip": "municipiu" },
{ "nume": "Cluj", "cod": 54932, "judet": "CJ", "tip": "județ" },
{ "nume": "Voluntari", "cod": 104630, "judet": "IF", "tip": "oraș" }
],
"meta": {
"actualizat": {
"administrativ": "2026-07-23T04:00:00Z",
"populatie": "2026-07-23T04:00:00Z"
}
}
}
- Localities
- 13.755
- API routes
- 89
- Version
- v1 · stable
- Import frequency
- daily
- Postal codes
- 54.571
- Licence
- public data
What you get in every record.
The fields below are guaranteed in v1. We add fields without changing the version, so your client has to ignore what it does not know.
What you can query.
/api/locations/v1/localitati
Localities
List and full-text search, filterable by county and type.
/api/locations/v1/localitati/{cod}
One locality
A single locality, with the full hierarchy on request.
/api/locations/v1/judete
Counties
Every county, with the number of localities in each.
/api/locations/v1/judete/{cod}/localitati
A county’s localities
The localities inside one county.
/api/locations/v1/regiuni
Regions
The development regions and the counties in them.
/api/locations/v1/cauta
Unified search
One search across every kind of unit.
What it is used for, concretely.
Address field
Suggestions as the user types, filtered by county if they have already picked one.
# 300 ms debounce in the client GET /api/locations/v1/localitati ?q=volun&judet=IF&limita=8
Addresses at checkout
You check that the locality–county pair really exists before you save the order.
# 404 if the pair is not valid GET /api/locations/v1/localitati/104630 ?include=judet
Geographic grouping
You aggregate orders by county or region on stable codes, not on hand-typed strings.
# the hierarchy, for rollups GET /api/locations/v1/regiuni ?include=judete
Where the data comes from and what you can do with it.
Source and updates
The data comes from the official administrative nomenclature and from public census sources. We normalise it: consistent diacritics, unit types mapped onto a fixed enum, hierarchy filled in where the source leaves it implicit.
The set is static — it changes only when a real administrative change happens (reclassification, renaming, a new commune). We check the source monthly and publish changes in the changelog. Every response carries `actualizat`, and the `x-data-updated` header tells you how old the set is.
Limits and licence
Official codes are stable: we neither reuse nor reassign them. A locality that is dissolved stays in the set with `stare: inactiva`, so old integrations do not break.
The data is public and you can use it commercially in your product, on any plan including Free. What you cannot do is redistribute the raw set as a competing product. Coordinates are approximate, at administrative centroid level — they are not exact address geocoding.