Skip to content

Structured Search

Structured search accepts well-formed address attributes instead of a single text field. Use it when you already have separate house number, street, locality, and region values and want to avoid ambiguities introduced by free-form parsing.

Try it: GET /search/structured

Provide any combination of the following fields. At least one field is required, and more context improves match confidence.

FieldExampleNotes
address30 West 26th StreetFull street line including house number.
localityNew YorkCity or town component.
regionNYState, province, or region.
countryUSCountry name or ISO code.
postalcode10010Optional postal or ZIP code.
county, borough, neighbourhoodManhattan, ChelseaSupply when you have finer-grained administrative info.

All structured queries also accept the shared filters from forward search: size, sources, layers, boundary.*, and boundary.country.

  • Include country whenever possible to improve ranking, especially for short street names.
  • Pair postalcode with address to disambiguate duplicate street numbers across districts.
  • Structured search falls back to Pelias parsing for missing components; providing more fields reduces the chance of ambiguous matches.
Terminal window
curl -s -G 'https://api-na.geobridge.io/v1/search/structured' \
-H 'Accept: application/json' \
-H "X-API-Key: ${GEOBRIDGE_API_KEY}" \
--data-urlencode 'address=30 West 26th Street' \
--data-urlencode 'locality=New York' \
--data-urlencode 'region=NY' \
--data-urlencode 'country=US'
  • Requests without any structured fields return HTTP 400. Validate input before calling the API.
  • size obeys the same 40-result ceiling as other Pelias endpoints; larger values are coerced and emit a warning in geocoding.warnings.
  • Combine structured search with /place to fetch authoritative details for the returned gid identifiers.