> For the complete documentation index, see [llms.txt](https://docs.mastersoftgroup.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mastersoftgroup.com/loqate-harmony-api/release-notes/release-2026-september.md). # Release 2026 September Planned on 24 September 2026 for version 2.20 ### At a glance HRA 2.20 brings the SaaS platform in line with the **2026 AMAS accreditation** requirements and refreshes the developer documentation and code samples. It also fixes two address-accuracy issues: (1) address line unification for Address Cleanse; (2) fixes the inconsistent results between V2 Find and V2 Retrieve. We've also upgraded the underlying Harmony libraries. No action is required from customers. There are no breaking changes to existing API contracts. *** ### What's new **AMAS 2026 accreditation support** HRA SaaS has been updated to the latest accredited address engine, covering the 2026 AMAS requirements for both address capture and verification. This includes updated handling of Parcel Locker and Parcel Collect addresses across V1 Cleanse, V2 Cleanse, V2 Find and V1 Address Lookup for the AUPAF data source (SOT). The detailed improvements are listed below. **What this means for you:** Address validation results reflect the current Australia Post accredited standard, and parcel delivery point addresses are matched more reliably. **Postal Address Matching** * **Addresses with both postal and street details now match correctly.** If your input includes a postal element (like a PO Box) alongside street information, the system now gives preference to the postal address instead of returning no match. *Example: "PO Box 7111, 1 Henley Beach Rd, Henley Beach South SA 5022" now correctly matches "PO BOX 7111, HENLEY BEACH SOUTH SA 5022."* * **Better recognition of alternate suburb names.** Postal addresses entered with a commonly used alternate locality name are now matched correctly. *Example: "PCL LKR 10, Ashgrove West QLD 4060" now matches "PCL LKR 10, ASHGROVE QLD 4060."* * **More accurate postal type matching.** Different postal address types (e.g., PO Box, Parcel Locker, RMB) are no longer cross-matched with each other or with unrelated street addresses. * **Parcel Locker addresses are now supported**, including common ways they're written: P/L, PL, Parcel Locker, PCL LKR. * **Parcel Collect addresses are now supported**, including common ways they're written: P/C, PC, Parcel Collect, PCL COL. **Street Address Matching** * **Street addresses can now be matched by postcode even if the suburb entered is incorrect.** *Example: "2 Daniels Lane, Yarrabilba / Bahrs Scrub QLD 4207" now matches "2 Daniels Lane, Yarrabilba QLD 4207."* * **Improved matching near suburb boundaries.** Addresses close to the border of two localities are now matched to the correct neighbouring suburb. *Example: "8 Embleton Ch, Mount Cottrell VIC 3024" now matches "8 Embleton Ch, Weir Views VIC 3338."* **Unit and Secondary Address Details** * **Unit/Level Detail Retention on Primary Point Matches** When the unit/level entered doesn't exist in the address data - resulting in a Primary Point Match rather than an exact sub-dwelling match - the unit/level detail you entered is now retained in the matched address, rather than being dropped. **Example** For input `DUP 16/5 Thornton St, Surfers Paradise QLD 4217` — "DUP 16" doesn't exist in the data, so the match falls back to the primary point (5 Thornton St): Before: `5 THORNTON ST, SURFERS PARADISE QLD 4217`\ After: `DUP 16, 5 THORNTON ST, SURFERS PARADISE QLD 4217` * **Unit/Flat Type Retention** APT, Unit, and Flat continue to be normalized to "U" as before - this hasn't changed. However, all other unit/flat types entered (for example, "Room", "Suite", "Kiosk", "Factory") are now preserved as entered, instead of being incorrectly converted to "U". Only APT, Unit, and Flat are treated as equivalent to "U" — any other unit type is retained from the input rather than being generalized. Applicable for the Cleanse API only. **Example** For input `RM 61/29 Brindley St, Belmont WA 6104`: Before: `U 61, 29 BRINDLEY ST, BELMONT WA 6104`\ After: `RM 61, 29 BRINDLEY ST, BELMONT WA 6104` *** ### Improvements **Refreshed JavaScript client sample in the console** The JavaScript integration sample shown in the HRA console has been updated to the current client library version. It previously referenced a long-superseded 2.0.1 release. **Corrected code snippets and "Get Code" output** The onSelect callback signature shown in the online documentation and in the console's Get Code option has been corrected to match the actual library behaviour (a single parameter). **Upgraded to Harmony Suite 4 libraries** HRA SaaS now runs on the Harmony Suite 4 libraries, including the updated Spring framework. This keeps the platform on supported, non-end-of-life dependencies and aligns HRA with the rest of the Harmony product family. *** ### Fixes **AddressLine Unification** The full address returned by Address Cleanse now matches the individual address components (building name, sub-dwelling, floor/suite, street, suburb, etc.) that are also returned in the response, for Australian addresses processed with AUPAF and AUSOTS. > **Example (AUSOTS)** > > For input `LOT 1 Fourteenth Ave, CRACOW QLD 4719`: > > Before: `LOT 1, FOURTEENTH AVE, CRACOW QLD 4719`\ > After: `LUSE GOOUSE, LOT 1, Fourteenth AVE, CRACOW QLD 4719` > > **Example (AUPAF)** > > For input `Floor 30 Suite L 44 MARKET ST, SYDNEY NSW 2000`: > > Before: `44 MARKET ST, SYDNEY NSW 2000`\ > After: `SE L, FL 30, 44 MARKET ST, SYDNEY NSW 2000` Previously, details like building names, unit/sub-dwelling numbers, and floor/suite information could be present in the component fields but missing from the full address. This is now fixed - the full address always reflects the complete set of components, so customers relying on it no longer lose that detail. **Base source no longer lost between V2 Find and V2 Retrieve** When searching against AUSOTS, an address returned by V2 Find was not preserved correctly when V2 Retrieve was called with the same ID, because the base source was handled inconsistently between the two calls. Find and Retrieve now return consistent results for the same address. *** ### Upgrade notes * **Breaking changes:** None. * **Customer action required:** None. Existing API keys, endpoints and request formats are unchanged. * **Response format note:** With address line unification enabled, the fullAddress value may differ from previous version for Address Cleanse API. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.mastersoftgroup.com/loqate-harmony-api/release-notes/release-2026-september.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.