Announcing the open beta of Addresses API 2.0
Introducing Addresses API 2.0
We’re excited to announce the open beta of the Addresses API 2.0. We’ve put a lot of work into the API and can’t wait to get feedback from our developer community on what you love, and what you wish we’d done differently.
Now, more than ever, building your business around trustworthy address information can make the difference between effectively serving your customers and not. The new Addresses API 2.0 is built on our daily-updated address dataset – a combination of G-NAF and the freshest national address data – to give you and your customers confidence.
What’s new in 2.0
Here are a few notable things about the new Addresses API 2.0.
New GeoJSON response body: With the release of Addresses API 2.0, we’re moving towards standardising on GeoJSON as our default response format. This improves accessibility and readability and enables many open libraries to parse and visualise the output of the new Addresses API.
Parsed user input always returned: One of the big user experience challenges, we’ve been told, is what to do when a match isn’t made. How can we more easily complete customer interactions? With Addresses API 2.0, in addition to returning an address match with quality metrics, we also default to returning the user input address parsed into discrete attributes. This will allow you to complete a form from user input even when we cannot match the address with enough confidence for you. It will reduce the amount of manual data entry you’re asking of your end-users.
Reduced transaction cost: Address validation, geocode and reverse geocode queries on the Addresses API no longer require multiple API calls to complete. The search and return of data can be completed in 1 call instead of 2. It only costs you 1 transaction and halves your transaction consumption.
Improved address searching and validation: The Addresses API 2.0 uses a completely new search engine built using machine learning and horizontally and vertically scalable systems in AWS. This allows us to make better matches, scale to much larger peak usage and keep response times to a minimum. Examples of better matching delivered by the new search engine include:
1. Fuzzy matching on misspellings and typos
2. Improved handling of multi-word suburbs (localities) and streets.
Address, street and locality geocoding: New to the Addresses API in V2.0 is the capability of returning a Street or Locality Geocode. By default, we will return the best possible geocode. However, where a geocode match is below a Match Quality of ‘Poor’, we’ll now return a better match at a different geocode level. But you’ll still have the ability to force the API to the specific geocode match type (Address/Street/Suburb) that works best for you.
Most commonly used attributes returned by default: With the introduction of GeoJSON, we now return geometry and address details by default in every result. You no longer need to make a second call to get that information. On top of that, we also allow the use of ‘additionalProperties’ to add other information into the response.
See the API spec and additionalProperties attribute.
New simpler API Documentation: From the release of Addresses API 2.0 Beta, we’re using a new API documentation tool. This tool still allows you to make calls from the API doc and test out the API. It still offers sample code in your choice of language and library. But it now also allows you to download the API spec in full as OAS 3.0. This opens new possibilities and enables you to self generate your API code.
See how to generate API code from OAS 3.0
Download the API spec here.
How to get started with the new Beta API
To get started with the new Addresses API 2.0 Beta, you need to be registered at the Geoscape Developer Portal and have opted into our Beta Program. The Beta Program is free and can be used non-commercially for evaluation and experimentation. Once registered, we’ll send you an API key, and you can get get started.
You can review the API spec here.
What’s coming next
- Street-level Geocodes in the reverse Geocoder
- Fixes to our match quality metric and match score
- More improvements to matching and bubbling the best match to the top position
- Use of cadastre to improve reverse geocoding
Please send us your feedback.
What do you like? What do you hate? Is there something you wish it did? What data about addresses should we be adding?