My Geocode

Guides

Geocode addresses that include apartment or unit numbers

· 4 min read · My Geocode · #forward-geocoding#apartments#address-parsing

An apartment number added onto a street address is a normal part of a lot of real addresses, and it is worth understanding how a geocoding lookup handles it rather than stripping it out before sending the request, which is a common but unnecessary habit.

Sending the full address

Include the apartment or unit number as part of the free-text query, the same as any other part of the address.

GET /v1/forward?q=Apt 4B, 350 Fifth Avenue, New York&limit=1
{
  "status": "ok",
  "query": "Apt 4B, 350 Fifth Avenue, New York",
  "results": [
    {
      "formatted": "350 Fifth Avenue, New York, NY",
      "lat": 40.7484,
      "lon": -73.9857,
      "type": "address",
      "precision": "house",
      "confidence": 0.95,
      "place_id": "es234",
      "components": {"house_number": "350", "street": "Fifth Avenue", "city": "New York", "region": "NY", "country": "US"}
    }
  ]
}

Why the unit number does not appear in coordinates

Coordinates from a geocoding lookup identify a building, not a specific unit within it, since individual apartments do not have their own separate mapped location the way a building does. The apartment or unit portion of an address is not expected to change the lat and lon values, and its absence from the components object is expected too, not a sign that the input was ignored or mishandled.

A second example: a suite number in a commercial building

The same pattern holds for a business address with a suite or floor number.

GET /v1/forward?q=Suite 200, 1 Example Plaza, Chicago&limit=1

A large office building housing dozens of separate businesses still geocodes to one set of building coordinates regardless of which suite is named in the query, exactly as an apartment building does. Anything distinguishing one tenant from another within that building needs to live in your own records, not in the coordinates.

A common mistake to avoid

Do not try to work around the missing unit component by appending it onto the postcode or another component field yourself after the fact, such as writing a postal code as "20500 Apt 4B". Doing this corrupts a field that other systems, including your own validation and any downstream address lookups, expect to contain only a real postal code. Keep the unit number in its own field entirely separate from every geocoded component.

Storing the unit number separately

Rather than folding the unit number into the address string you geocode every time, store it as its own field in your own data model alongside the geocoded building address. This keeps the geocoding request focused on what actually affects the result, the building's location, while still preserving the unit information for delivery labels or internal records.

When it matters for delivery

A courier or postal service needs the unit number for actual delivery, even though it played no role in the coordinates. Keep both pieces, the geocoded building coordinates and the separately stored unit number, together in the final delivery record so nothing gets lost in the process.

An edge case worth knowing

A single building address can house a large number of separate residents or tenants, all sharing the same coordinates and the same postal code lookup result. If you are cross-checking a customer's postal code against a forward geocoded address, as covered in the postal code cross-check guide, remember that this many-to-one relationship between units and a building is expected and is not itself a sign of a data problem.

Cost is unaffected

Whether or not an address includes an apartment or unit number, the lookup still costs one request, the same as any other forward geocoding call.

Including a unit number in the query does no harm, and stripping it out is not necessary for accurate geocoding, though separating it into its own stored field afterward keeps your data cleaner. See the forward geocoding docs for the full components list.

More in Guides