# Expanded sub-premise reach

## What is  Expanded sub-premise reach?

Increases your successful address searches for ungazetted sub-premises. These are commonly newly created developments, commercial addresses, retirement homes, land lease, shopping centers. These addresses are present in our authoritative data at a building or premise level, however, often the customer will request an address at their known sub-premise. This feature solves that issue by solving the last metres for successful delivery.&#x20;

Our technology recognises the sub-premise has been requested for valid address and handles it appropriately.

### How user derived address changes responses

Loqate AU NZ expanded sub-premise alters the address options the end user selects because of the end users input to recognise sub-premise.&#x20;

**Without expanded sub-premise**

The unit information is not used because within the data no unit exists at this address. However, the end user is requesting a unit. If the customer selects the premise the end deliver can fail as the delivery driver does not know which sub-premise the deliver is for.

![](/files/VCZLUp4FSuZ5OlLCmzmv)

**With expanded sub-premise**

The unit information is now available for the end user to select as they have searched for it. Importantly, the premise level is what the validated address is linked with. The delivery driver has clear instruction to make the delivery.

![](/files/MDoyDPj9uXSKpiUxiIFr)

### How to Implement **Expanded sub-premise**

Add in call featureOptions "userInferred": "1". This is the only change you need to make. Address Retrieve works normally based upon the "id" supplied in Address Find.

```json
    {
        "payload": [ { "country": "au", "fullAddress": "suite 4 20 bond st, nsw" } ], 
        "sourceOfTruth": "AUPAF",
        "featureOptions": { "userInferred": "1", "singleLineHitNumber": "5" }
    }
```

## How do I know **expanded sub-premise** has been used?

When a expanded sub-premise has been selected in Address Find by the customer this confirms the inference eg That the end customer wants to use this address.

The Address id contains the UserInferred detail eg "AU|AUPAF|68930608|UNIT 2".

When calling Retrieve include this full ID containing the User inferred information.

Within the response data ***payload.attributes.UserInferred*** has the value of the userInferred input.

Population of this field

<pre class="language-json"><code class="lang-json">{
    "status": "SUCCESS",
    "messages": [],
    "payload": [
        {
                ...
            "attributes": {
                 ...
                <a data-footnote-ref href="#user-content-fn-1">"UserInferred": "UNIT 5"</a>
            },
            "id": "AU|AUPAF|68930608|UNIT 5",
        ...
        }
    ]
}
</code></pre>

## Which sub-premise types does it work for?

For AU & NZ all of them.&#x20;

Our technology recognises the sub-premise patterns for valid address and handles it appropriately seamlessly in our api response.

[^1]:


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.mastersoftgroup.com/loqate-harmony-api/guides/expanded-sub-premise-reach.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
