Address API for test and UAT environments

The problem

A normal test key stops working 15 days after the account opens. After that, a UAT environment has to run on a live key. Every lookup is then billed and comes out of the same monthly quota as production. For a team that tests every night, that is a real cost, and it can use up the lookups your customers need.

How it works

Create a test key in the console for each environment. It behaves like a live key with the same engine and the same G-NAF data. The differences are that it is never billed and that it has limits suited to testing. These limits apply by default, and we can set different limits for your workspace.

A test lookup is counted the same way a live lookup is billed. One address search session is one lookup. Address autocomplete keystrokes never count. A suburb and postcode search session counts once. At the cap, the API returns 402 test_cap_reached. Nothing is charged, and test lookups start again at the start of the next billing period.

Enterprise is the only plan with this. Every other plan keeps test mode for the first 15 days of the account. Where we have not switched the option on for a workspace, or the option has ended, the 15-day rule applies.

The Plans, usage and metering section of the Terms of Service sets the conditions. In short:

• We switch this on for your workspace by written agreement. An email exchange with the account owner is enough.
• Test keys are for development, testing and training only. They are never for production or for serving your users.
• Performance and load tests use a live key and are billed. They need our written agreement to the date and rate first.
• Test keys can stop when your workspace’s billable lookups are refused.
• Test keys are not covered by the SLA.
• We can change the limits or switch the option off on 30 days’ notice by email to the account owner. If that lowers the limits or switches the option off, you may cancel as the Terms describe.
• The option ends when the workspace leaves Enterprise or has neither a contracted volume nor an agreed test cap.
• We can suspend test keys straight away if we reasonably believe they are being misused. If we do, we tell the account owner why and restore them once the breach stops.

One key per environment

Give each environment its own key, named for it, such as sit-checkout or uat-claims. Lock each browser key to the domains of that environment, and each server key to its own IP addresses. A key that is not locked can be used from anywhere, and it would spend your test cap and your shared test rate. The console warns when a browser test key has no domains. You can revoke one environment’s key without touching another’s.

Test responses say so

Retrieve, verify, reverse geocoding and suburb and postcode retrieve and verify return "test": true on a test key. Use it in your own checks to be sure a test environment is not calling production by mistake. Autocomplete responses do not carry the flag.

Hosted in Australia

Test keys run on the same Australian infrastructure as live keys. Requests are processed in Sydney, or in Melbourne if Sydney is not responding, on infrastructure operated by an Australian company. Read the data residency attestation for what that covers.

Copied production data

Test data is often copied from production, so a test search can contain a real customer’s address. Test searches go into the workspace’s search log under the privacy mode of the key, and are kept for the retention you set. For test keys, use the keyed hash mode or the no-store mode. Keyed hash is pseudonymisation, not anonymisation, because we hold the key. No-store keeps no query or matched-address text at all. The privacy policy describes both.

Questions

The setup steps are in the test environments guide. Procurement questions are answered on the government and regulated industries page.