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.
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… [ Learn More ]
The Property Emergency Services API is a means to access location information for Australian police stations, ambulance stations, fire stations, and SES facilities. For most users, this API information isn't necessary nor relevant, but many have technical skills that permits them to integrate various types of data with their existing applications. The API itself is… [ Learn More ]
The Property Railway Station API is a means to access the location of Australian railway stations. 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. The API itself is used extensively by the Yabber property modules.
Articles relating to the Yabber and Website Property modules.
This FAQ details the methods necessary to create a parent Property API Key. While the Property modules are intrinsically connected with all our modules, it operates autonomously via a standalone API-centric system that connects with multiple external applications. In order to use the Property module, you must first be assigned to the module (which is… [ Learn More ]
In a previous FAQ we looked at how to include an address validation field into a form on your website. This FAQ will introduce the same style of field that will automatically direct the user to the single page associated with each registered address in Australia. This feature is part of the broader Property… [ Learn More ]
The Property Property Streets API, and the Validation Endpoint in particular, is a means to access registered street and registered address location from Yabber via a form input field. The Validation (or Autocomplete) endpoints are useful for searching property on user keystrokes. The validation may be used to ensure pinpoint accuracy is assured by way… [ Learn More ]
SMS Subscription forms may be used in any number of ways, but the primary purpose is to support text message alerts for various types of property opportunities. When the form was first introduced, the form was part of our supporting partner modules, but more and more brokers are becoming affiliate directly with property groups, and… [ Learn More ]