Catalog updates: every refresh, dated
The official catalog ships one last-updated date and no history, so there is no way to tell a release that changed nothing from a release you missed. This page is the record for the copy PostalKit serves: one row per run, including the months the source did not move.
- Last checked
- 2026-08-14
- Last changed
- 2026-08-14
How the catalog is kept current
-
Checked on the first of every month.
A scheduled job downloads the published catalog at 03:00 and compares it against the copy already imported.
-
Compared by hash, not by date.
The check is a SHA-256 of the downloaded file. If it matches, nothing is imported and nothing moves, so a difference in the data always means the source really changed.
-
Reconciled, not just added to.
A colonia the postal service retires is retired here too, so what you read back is the current catalog rather than everything that has ever been in it.
-
Identifiers stay put.
A refresh matches on the postal code and the INEGI keys rather than reloading the catalog from scratch, so the ids you stored last month still resolve this month.
The record
Every run, newest first. A run that found the source unchanged is listed too — that is the difference between a catalog that was checked and one that was merely left alone.
| Run | Result | Postal codes | Colonias | Municipios | Cities | Estados |
|---|---|---|---|---|---|---|
| 2026-08-14 | Updated | — | — | — | — | — |
Read as added, changed and retired. A dash means that run predates this record and its detail was never captured.
What a change actually means
-
A rename shows up twice.
A colonia is identified by its name within a postal code, so renaming one retires the old entry and adds the new one. A month with matching additions and removals is usually the postal service tidying up spellings.
-
A changed row is a changed field.
The middle number counts colonias whose zone moved between urbano, rural and semiurbano. A refresh that re-reads a row without altering it is not counted.
-
A quiet month is a real answer.
The postal service does not publish on a fixed cadence. Several checks in a row finding nothing is normal, and it is why the check is recorded separately from the change.
From your own code
Ask the API which version you are reading
The same record is one request away, so a deployment can decide for itself whether anything is worth re-syncing:
GET /v1/account/db-version
It answers with both dates:
{
"data": {
"last_updated": "2026-08-01T03:00:00.000000Z",
"catalog_version": "2026-08-01",
"last_checked_at": "2026-09-01T03:00:00.000000Z",
"version": "1.0.0"
}
}
last_checked_at moves every month whether or not the catalog did, so a last_updated that has not moved in months means the official source has not moved — not that anything stopped running.
- postal codes
- 31,880 postal codes
- colonias
- 159,019 colonias
- municipios
- 2,478 municipios
- estados
- 32 estados
Where this catalog comes from, and what the official export leaves you to solve, is on the SEPOMEX catalog guide. The endpoint above is documented in the API reference.