Most fields are not something you’ll normally need to care about for your application development, but it contains some useful debugging information. We’ve mentioned the noteworthy fields below; the rest should be self-explanatory.
Field
Description
attribution
A URL containing attribution information. If you are not using Stadia Maps and our standard attribution already for your basemaps, you must include this attribution link somewhere in your website/app.
query
Technical details of the query. This is most useful for debugging during development. See the full example for the list of properties; these should be self-explanatory.
warnings
An array of non-critical warnings. This is normally for informational/debugging purposes and not a serious problem.
errors
An array of more serious errors (for example, omitting a required parameter). Don’t ignore these.
Any feature which can be represented as a single geographic point will be a point. Places which are an area (such a a city) are centroids. Note that this field does not necessarily indicate anything about the quality of a result (unless you are looking specifically for address or venue points).
addendum
Optional additional information from the underlying data source (ex: OSM). This includes select fields. The Wikipedia and Wikidata IDs and the website (all optional) are probably the most useful for OSM results.
Scoped GIDs referencing the underlying dataset. These are generally stable IDs.
source_id
An ID referencing the original data source (specified via source) for the result. In the case of OSM, these typically look like way/123 or point/123.
label
A full, human-readable label. However, you may not necessarily want to use this; be sure to read about name, locality, and region before deciding. This field is mostly localized. The order of components is generally locally correct (ex: for an address in South Korea, the house number appears after the street name). However, components will use a request language equivalent if one exists (ex: Seoul instead of 서울 if lang=en).
name
The name of the place, the street address including house number, or label of similar relevance. If your app is localized to a specific region, you may get better display results by combining name, locality OR region (or neither?), and postal code together in the local format. Experiment with what works best for your use case.
locality
The city, village, town, etc. that the place / address is part of. Note that at this time, the matching is a bit crude, so values may not always match postal or local conventions perfectly. This is an area of active development.
county
Administrative divisions between localities and regions. Useful for disambiguating nearby results with similar names.
region
Typically the first administrative division within a country. For example, a US state or a Canadian province.