GBG Loqate - Reach

Loqate CLI

Verify addresses, emails, and phone numbers against Loqate's APIs.

Get confidence scores, policy-aware recommendations, and full auditability — in one command.

Real-time verification decisioning for agents that need to know whether contact data is good enough for the job.

Part of GBG Reach .

lqt verify · lqt parse · lqt mcp

---

Install

macOS

# Apple Silicon (M1/M2/M3/M4)

curl -sL https://github.com/gbgplc/lqt/releases/latest/download/lqt_darwin_arm64.tar.gz | tar xz sudo mv lqt /usr/local/bin/

Intel

curl -sL https://github.com/gbgplc/lqt/releases/latest/download/lqt_darwin_amd64.tar.gz | tar xz sudo mv lqt /usr/local/bin/

Linux

# x86_64

curl -sL https://github.com/gbgplc/lqt/releases/latest/download/lqt_linux_amd64.tar.gz | tar xz sudo mv lqt /usr/local/bin/

ARM64

curl -sL https://github.com/gbgplc/lqt/releases/latest/download/lqt_linux_arm64.tar.gz | tar xz sudo mv lqt /usr/local/bin/

Windows

1. Download lqt_windows_amd64.zip from the latest release
2. Extract lqt.exe
3. Move it to a directory on your PATH, or run it directly

Verify Installation

lqt version

All Downloads

See Releases for all versions and platforms. Each release includes SHA-256 checksums.

---

Quick Start

API Keys

You need a Loqate API key for verification. Optionally, an Anthropic API key for the parse command.

macOS / Linux:

export LOQATE_API_KEY=your-key-here

Optional — for lqt parse

export ANTHROPIC_API_KEY=your-key-here

Windows (PowerShell):

$env:LOQATE_API_KEY="your-key-here"

Optional — for lqt parse

$env:ANTHROPIC_API_KEY="your-key-here"

Your First Verification

macOS / Linux:

# Verify an address

lqt verify --address "125 Summer Street, Boston, MA 02110, US"

Verify address + email + phone with a policy

lqt verify -a "10 Downing St, London, GB" \ -e "pm@gov.uk" \ -p "+442071234567" \ --policy shipping

Parse and standardize without calling Loqate (uses Claude)

lqt parse --address "125 summer street boston ma 02110 us"

Windows (PowerShell):

# Verify an address

.\lqt.exe verify --address "125 Summer Street, Boston, MA 02110, US"

Verify address + email + phone with a policy

.\lqt.exe verify -a "10 Downing St, London, GB" -e "pm@gov.uk" -p "+442071234567" --policy shipping

Parse and standardize without calling Loqate (uses Claude)

.\lqt.exe parse --address "125 summer street boston ma 02110 us"

---

Commands

verify

Verify addresses, emails, and/or phone numbers against Loqate's APIs. Returns a confidence score and a policy-driven recommendation (accept, review, or reject).

lqt verify [flags]

Flags:

Examples:

# Simple address verification

lqt verify -a "1600 Amphitheatre Parkway, Mountain View, CA 94043, US"

Multi-field verification with strict policy

lqt verify -a "221B Baker St, London, GB" \ -e "sherlock@example.com" \ -p "+442071234567" \ --policy strict

Email-only or phone-only (no address required)

lqt verify -e "sherlock@example.com" lqt verify -p "+442071234567"

Guess a missing country from the address (opt-in, address-only)

lqt verify -a "10 Downing St, London SW1A 2AA" --detect-country

→ result includes: country_guessed, detected_country, country_confidence

Suggest alternatives when the address does not clear the policy (opt-in, address-only)

lqt verify -a "10 downin st london" -c GB --suggest lqt verify -a "10 downin st london" -c GB --suggest --suggest-limit 3

→ result includes: address.suggestions with a list of candidate addresses

Accepted but not confident: a street-level match accepted at 0.55 still gets alternatives

lqt verify -a "marsh wall, E14 9TN" -c GB --suggest

Move or disable the confidence floor

lqt verify -a "marsh wall, E14 9TN" -c GB --suggest --suggest-below 0.95 lqt verify -a "marsh wall, E14 9TN" -c GB --suggest --suggest-below 0

JSON output for piping to other tools

lqt verify -a "10 Downing St, London, GB" -o json | jq '.address.confidence'

Extended input fields

lqt verify -a "125 Summer St" --field Organization="Acme Corp" --field Building="Suite 200"

API options (dot notation for nesting)

GeoCode is sent at the request root as a JSON boolean (where Loqate expects it);

ServerOptions values are sent as strings (use Loqate's exact casing).

lqt verify -a "125 Summer St, Boston, MA 02110, US" --option GeoCode=true lqt verify -a "125 Summer St, Boston, MA 02110, US" --option ServerOptions.OutputCasing=Upper

Full list of input fields and API options: Loqate International Batch Cleanse API

Address suggestions (--suggest)

Licensing. Suggestions use a Loqate feature that is **licensed separately from address

verification** and must be enabled on your account. If it isn't, nothing breaks: the

verification still returns its normal result and exit code, and the reason appears in

suggestions.error (typically an unknown-key or licence message from Loqate). Talk to your

Loqate account contact to have it enabled.

Verification tells you an address is wrong. Suggestions tell you what the right one probably is. Add --suggest and lqt asks Loqate for real addresses matching what was typed, returning them with the decision.

The lookup runs when either:

1. the address was not accepted (review or reject), or
2. the address was accepted but scored below the policy's suggestion floor (0.85 on standard — see the Policies table).

The second case is the one that catches near-misses. A policy accepts anything at or above its minimum confidence, so *accepted* is not the same as *confident*: on standard the input marsh wall, E14 9TN matches a street and scores exactly 0.55, which is accepted — yet the house number is missing and better addresses exist. Use --suggest-below to move that line (--suggest-below 0 turns the confidence check off and only suggests on review/reject).

{

"address": { "verified_address": "Downing Street, London", "confidence": 0.5, "recommendation": "review", "suggestions": { "requested": true, "triggered": true, "reason": "accepted but confidence 0.55 is below the 0.85 floor", "floor": 0.85, "source": "loqate", "count": 2, "items": [ { "id": "GB|RM|A|52509479", "type": "Address", "text": "10 Downing Street", "description": "London, SW1A 2AA", "address": "10 Downing Street, London, SW1A 2AA" }, { "id": "GB|RM|A|52509480", "type": "Address", "text": "11 Downing Street", "description": "London, SW1A 2AB", "address": "11 Downing Street, London, SW1A 2AB" } ] } } }

Things worth knowing:

• Off by default, so existing output is unchanged unless you ask for suggestions.
• No lookup for a confidently accepted address — you pay the extra latency only where it helps. The suggestions block is still returned with "triggered": false and a reason, so you can tell "no alternatives needed" from "suggestions were never requested".
• `floor` reports the threshold that was applied, so you can see why a lookup ran (or didn't) without knowing the policy's configuration.
• Suggestions never change the decision. If the lookup fails, the reason appears in suggestions.error and the verification result stands.
• Address-only. With verify --email / --phone, or verify_contact, only the address block is decorated.
• An entry with "expandable": true is a street, postcode, or building holding several addresses rather than one deliverable address. Search within it for a specific premise.
• Suggestion lookups do not consume Loqate verification credits, but the feature must be licensed on your account (see the note above).
• Suggestions need a standard Loqate key (--key / LOQATE_API_KEY); --verify-key alone covers address verification only.
• Not available with `--batch`. A large file would fan out into an unbounded number of lookups, so the combination is rejected. Verify the file, then re-run the flagged rows individually with --suggest.

Available on the MCP verify_address / verify_contact tools and the REST /v1/verify/address / /v1/verify/contact endpoints as suggest: true, with optional suggest_limit (1–10, default 5) and suggest_below (0–1).

Closing the loop: offer, choose, re-verify

A suggestion is a candidate, not a verdict. Items carry no confidence score, no match level, and no AVC — they a