My Geocode

Guides

Handle addresses with no house number

· 3 min read · My Geocode · #forward-geocoding#precision#edge-cases

Not every address has a house number. Rural routes, some new developments, and well-known landmarks are often referred to without one, and a geocoding request built around expecting a house number every time will misread what a valid result for these looks like.

What the response looks like without one

GET /v1/forward?q=Golden Gate Bridge, San Francisco&limit=1
{
  "status": "ok",
  "query": "Golden Gate Bridge, San Francisco",
  "results": [
    {
      "formatted": "Golden Gate Bridge, San Francisco, CA",
      "lat": 37.8199,
      "lon": -122.4783,
      "type": "address",
      "precision": "street",
      "confidence": 0.9,
      "place_id": "gb567",
      "components": {"city": "San Francisco", "region": "CA", "country": "US"}
    }
  ]
}

Notice there is no house_number field in components here, and precision reads "street" rather than "house". Both of these are expected for an address that genuinely does not have a house number, not signs of a failed or partial lookup.

Reading precision correctly

Treat precision as a description of how specific the match is, not as an error indicator. A "house" precision means the match resolved to a specific building. A "street" precision means it resolved to a street or a point along it, without pinning down an exact building, which is exactly right for a landmark or an address genuinely lacking a house number.

A second example: a well-known public space

GET /v1/forward?q=Central Park, New York&limit=1

A named public space like this typically resolves with type set to something broader than "address" and a precision that reflects an area rather than a single point, along with a components object that may include only a city and region. This is the same pattern as the bridge example: a real, useful result described honestly as covering an area rather than a specific building, because that is what the query actually referred to.

Adjusting validation logic accordingly

If your form validation currently requires a house_number field to be present before accepting an address as complete, that check will incorrectly reject legitimate rural addresses and landmarks. Base acceptance criteria on confidence and precision matching what you actually need, rather than requiring every specific component to be populated.

A common mistake to avoid

Do not treat an empty components object, or one missing several fields, as equivalent to a failed request. A failed request comes back with an error status and an error code, described on the errors docs. A successful result with sparse components is a different, entirely normal outcome, and conflating the two in your error handling will cause valid addresses to be logged and treated as failures.

Letting customers confirm instead of reject

For an address without a house number, showing the formatted result back to the customer for confirmation works better than rejecting the submission outright. This keeps a real address usable while still catching genuinely bad input elsewhere.

The reverse direction has the same pattern

Reverse geocoding a coordinate that sits in open countryside or water can likewise come back with a coarser precision and fewer populated components than a coordinate sitting on a specific building's footprint. The reverse geocoding docs describe the same precision values from that direction.

Cost stays the same

An address without a house number costs the same one request as any other forward geocoding lookup. Nothing about missing components changes how the request is billed against your daily allowance or credit balance.

Handling this correctly is mostly about reading precision and confidence as intended, rather than assuming every valid address must fully populate every component. The forward geocoding docs explain each field in detail.

More in Guides