How to Use the Property Streets API

The Property Streets API is a means to access registered street and address data from Yabber. For most users, this information isn't necessary nor relevant, but many have technical skills that permits them to integrate various types of data with their existing applications. Other Property FAQs show how to assign property widgets and video to these pages, or default widgets and video when no media is specifically assigned for the geographical tier. Activation of this module adds around 16-million individual pages to your website (supporting the every-page conversation methods). The API itself is used extensively by the Yabber property modules.

Property Module: Yabber's Property Module is extensive. The module makes property listing, analytical, and other data available to you, your child users, and partners. A large number of APIs may be used to access data for other applications. Review an introduction to the Property Module here. A commonly referenced FAQ details how to include a Property Listing Widget on your website, and another details how to assign a property to an existing widget location.

Property API Key: The Property API Key is different to your standard 'Personal' API Key and must be accessed through the Property Module  (and then saved on your website ). The Property Module is a completely standalone module that integrates directly with Yabber. Basic API Documentation introducing the Property API may be found here.If you would like to access the API programmatically, you may reference a basic PHP function here.

Endpoints that return mapping, street coordinate, and spatial data, are not introduced in this FAQ and will instead be documented elsewhere. Many of the responses in this FAQ have already changed, but the full documentation is forthcoming.

The primary purpose of this data on your own website is to facilitate property and suburb reports.

  Introduction

The Streets API is a standard read-only RESTful API providing up-to-date access to every street and registered address in Australia. The street data is made available on client websites from a backend geographic search engine. Data is updated every Monday so we suggest you set any cached data to expire after 3pm on that day. No limitations are applied for general use.

  Property API Endpoint

The Endpoint for all requests to the Property API is structured as follows:

api.beliefmedia.com/property/{category}?/{action}.json?apikey={apikey}

The preferred method of authentication of your API Key is in the Authorisation Header (Authorization: Bearer {token}) as support for the URL parameter will soon be deprecated. Requests to child datasets will always include a {category} while the primary (listing) property endpoint is accessed directly. More information on the Property API is available here.

  Streets API

Queries to the Streets API are made to property/streets/{action}.json with selected action types listed in this FAQ.

  Suburbs

The property/streets/suburbs.json endpoint returns a single response with all Australian suburbs (that include streets). They are indexed on the suburb_id that may be used in various property queries. No URL parameters are accepted.

The response is quite large. You should request this endpoint with each data update and cache as required. It's highly unlikely that any of the values will change.

  States

The property/streets/states.json endpoint returns a single response with all Australian states and territories. Values are indexed on the state_id that may be used in various property queries. No URL parameters are accepted.

  Street Suffix and Street Type

The property/streets/street_suffix.json endpoint returns a single response with all street suffix values, while the The property/streets/street_type.json endpoint returns a single response with all street type values. Values are indexed on the suffix_id and type_id respectively, both of which might be used in various property queries. No URL parameters are accepted.

  Stats

The property/streets/stats.json endpoint returns a single response with the total number of addresses, all suburbs with the number of streets in each, and the number of addresses of type. The information is simply for reference in graphing tools and should be cached after each update.

  Locality

The property/streets/locality.json endpoint returns a single response with data relating to a single postcode.

The endpoint requires the parameter of postcode and an optional state (streets/locality.json?postcode=2138&state=nsw). Note that the streets_density_postcode key includes the number of addresses listed on each street. To include all the addresses for a postcode you should include the parameter of &streets=1 (keeping in mind that the response is quite large).

  Addresses

The property/streets/addresses.json endpoint returns addresses on a single street. Required URL parameters includes the state_slug (lower-case two or three-letter state representation), street_slug, and postcode. A request to addresses.json?state_slug=nsw&street=moala-street returns something similar to the following:

Note that the 'street slug' is passed as street. The postcode is optional but generally required to avoid the response returning property on the same street in different localities or states. You may mitigate the risk of geographically irrelevant streets with the parameter of street_id.

Note that each property includes a property_id, locality_name_slug, and key. Either of these values may generally be used to query properties when a property_id is required.

  Address

The property/streets/address.json endpoint returns addresses on a single street. The property_id (as noted above) is required. A request to address.json?property_id=11010201 returns something similar to the following:

The locality_name_slug value is generally required when each property is listed on a website and a unique and SEO-friendly URL is required. The distance key returns the distance to the reference Post Office in kilometres, miles, and nautical miles.

  Streets

The property/streets/streets.json endpoint returns paginated addresses on a single street. A postcode, page number, and limit is required (limit is the number of results returned to each page). A request to streets.json?postcode=2138&page=4&limit=3 returns something similar to the following:

  Suburb

The property/streets/suburb.json endpoint returns all streets in a single locality. The suburb (slug) and state is required. An optional postcode may be provided to limit results to streets within a defined postal region.

A request to suburb.json?suburb=burwood&state=nsw&postcode=2134 returns the following:

  Radius and Nearest

The property/streets/nearest.json (and similar radius) endpoint returns all streets within a specific radius of a defined geographical position. A property_id OR latitude and longitude reference point is required. A radius in kilometres is also required (although results are returned in metres).

The supplied property_id may be a numeric ID (as returned in various responses), and the key associated with each record, the GA PID. A request to property/streets/nearest.json?id=299062 unwraps something similar to the following:

  Browse

The property/streets/browse.json endpoint is provided for the purpose of browsing every result in paginated format. The only accepted URL parameters are page, limit, orderby, and order. Exmaple: browse.json?page=3&limt=20&orderby=id&order=asc returns:

You may orderby on id, name, suburb, postcode, address, or state, and you may order by asc or desc.

  Search

The more popular property/streets/search.json endpoint is provided for the purpose of searching every result in paginated format. You may search on the following values (all are wildcard, so partial matches are accepted):

• street
• suburb
• postcode
• latitude and longitude
• state

For example, a request to search.json?street=moala&suburb=concord&postcode=2138 unfold to an array resembling the following:

You may orderby on id, name, suburb, postcode, address, or state, and you may order by asc or desc.

  Validate and Autocomplete

The address validation endpoint will accept an address and return matching addresses. It may be used via standard GET request but is more typically used asynchronously to provide address suggestions while a user types into a text field. The feature is introduced in an FAQ titled "How to Use the Property Address Validation API and Autocomplete Form on My Website".

The endpoint for the asynchronous or other request is validate.json?q-address=8%20moala%20st%20concord%20west%20nsw%202138.

Both the validate and autocomplete actions are similar with the exception that the validate option provides a facility for header and more information. Up to 20 partial matches are returned in a single response which are ordered based on field priority (street, suburb, postcode etc). The naked query string accepts multiple formats which are interpreted server-side making it suitable for address validation with form submissions.

This endpoint cannot be accessed outside whitelisted IP addresses, and a time-limited validation key is required in addition to the standard API Key with each request. This protection is automate on client websites.

The consumer-facing functionality of the endpoint are introduced in an article titled 'How to Use the Property Address Validation API and Autocomplete Form on Your Website'. Another article titled 'Address Autocomplete Form Linking to Dedicated Property Page' shows how to link directly to any of the millions of pages generated with the tool.

  Conclusion

Results on this page were truncated for readability and they should be used for illustrative purposes only. The primary purpose of the API is to link into Yabber's broader property module, but the feature in isolation often provides value.

  Related FAQs

Article relating to the Property API.

Articles relating to the Yabber and Website Property modules.