Wiring Mexican postal codes into your stack

The part that is the same everywhere

There is no SDK to install and nothing to configure. It is HTTPS, a Bearer token in a header, and JSON coming back. If you can read this call you can already read all four pages below.

curl -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Accept: application/json" \
     https://api.postalkit.mx/v1/postal-codes/06600

The Accept header is not decoration. Ask for a route that does not exist without it and you get an HTML error page rather than JSON, and the first thing that breaks is your parser rather than your error handling.

Pick the one you are working in

• Laravel Laravel 13.25 · PHP 8.5

  A service class over the HTTP client, a cache that survives a code that does not exist, and a validation rule that rejects a bad postal code before the form saves.

• Node.js Node 22.23 · Express 5.2

  A client in forty lines of built-in fetch, an error type worth catching, and the route that keeps your API key on the server where it belongs.

• Python Python 3.14 · requests 2.34

  A pooled session with retries, the two different 429s and how to tell them apart, and enriching a spreadsheet of addresses without spending the month on it.

• React React 19.2

  The address form that fills estado and municipio in and offers the colonia as a list — debounced, cancellable, and with no API key anywhere in the bundle.

Read the one for the layer you are writing. The React page is the exception: it assumes you have a backend and tells you to put one request behind it, so it reads better after whichever server-side page is yours.

If you are not at the code yet

These pages assume you already know which call you want. If you do not, the use-case pages start from the question instead — for example turning a postal code into an address or finding a colonia by name.

Every parameter, field and error code lives in the API reference, and the same endpoints are published as an OpenAPI spec if you would rather generate a client than write one.