Use the HtAG API Playground: test a request and take the code with you

Use the HtAG API Playground to configure a small request, inspect its response and take the corresponding code into your application. It calls live endpoints, so check billing and the expected result size before sending.

1. Choose the right API family

The Playground has four modes: Public API, Internal API, Agent APIs (REST) and Agent Demo (MCP). Begin with Public API when learning the property and market data endpoints. Internal or partner access depends on your account; choose only the services available to you.

Within Public API, the visible categories are Address & Property, Markets, Demographics, Economics, Reference, Concordance and Spatial. Choose a category, then use the endpoint selector to pick the operation you want to explore.

2. Select your key and check costs

Choose a key from the API KEY selector. If you need to manage your keys, visit Authorization. Check Billing and the current rate card before executing the request.

Public data requests can return multiple billable units. Paid research agents are billed per execution; the agent screen explicitly flags paid runs. Read the cost-management guide before testing a broad search or agent workflow.

3. Start with a locality lookup

Select Public API → Reference → Locality Lookup. The form includes Name, Loc PID, State Name, LGA PID, Postcode, Limit and Offset. You do not need every filter: use a combination that identifies your intended place.

For a small example, enter Richmond as Name, VIC as State Name and 3121 as Postcode. Set Limit to 5 and Offset to 0. At the time this guide was prepared, the form displayed a default Limit of 100; replace it deliberately rather than accepting a larger default.

Check the generated request before pressing Send Request. Inspect the returned matches and retain the correct locality identifier for later requests. Do not choose a result solely because its name matches: check the state, postcode and other returned context.

4. Inspect the response and the code

The Playground exposes Response and Code views, with cURL, Python and Node.js code choices. Compare the generated URL and parameters with the form, then examine the response before expanding the request.

The locality example targets https://api.htagai.com/v1/reference/locality and authenticates with x-api-key. A small request would look like:

curl "https://api.htagai.com/v1/reference/locality?name=Richmond&state_name=VIC&postcode=3121&limit=5&offset=0" 
  -H "x-api-key: YOUR_API_KEY"

Copy only the example you need. Store your real key securely and remove secrets before sharing code or screenshots. Use the API reference to confirm the selected endpoint’s parameters, response schema and limits.

5. Try address standardisation when formatting is the task

Under Address & Property, Address Standardisation accepts a list of Australian address strings, with up to 50 addresses per call. The form provides an address row, Add address and a control to standardise the entered addresses. It also notes that Enter adds a row.

Start with one address, inspect the components and generated address key, then expand the list if needed. Standardisation is a formatting operation. It does not replace reviewing a geocode match when your workflow must resolve a property in the database. The core concepts guide explains the distinction.

6. Treat an agent run as its own workflow

The Agent APIs (REST) mode exposes paid research workflows. The inspected Market Cycle Timing form asks for a suburb and state, with property type, bedrooms, an option to include historical cycle chart data and explanation depth. Its action is Run agent.

Review those inputs and the per-execution price before running. An agent execution is a different billing unit from a data endpoint’s returned rows. The Agent Demo (MCP) mode is a separate Playground entry point; follow its displayed connection and input requirements for your chosen demo.

7. Move one verified request into your application

Once the small request works, use the generated code as a starting point. Add secure key storage, error handling, explicit request bounds and logging of returned billing headers. Every successful billable response carries cost and usage telemetry; see the billing-header examples for Python and browser JavaScript.

The Playground helps you learn a request. Your production application still needs its own pagination policy, retry limits, caching and cost controls.

Your Playground checklist

• The correct API family and endpoint are selected.
• Your key and billing access are ready.
• Filters, Limit and Offset are deliberate where supported.
• The returned place or address matches the intended input.
• You understand the response shape and cost before making a larger request.
• Copied code contains no exposed secrets.

Open the Playground or return to the Get started collection. To plan a larger workflow, read our Use Case Builder guide.