Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.loqate.com/llms.txt

Use this file to discover all available pages before exploring further.

Policies define the thresholds that determine whether contact data is accepted, flagged for review, or rejected. Every verify call evaluates results against a policy to produce an actionable recommendation.

​
Built-in policies

Reach ships with four policies covering common use cases:
PolicyAddress ConfidenceMatch LevelEmail ConfidencePhone RequiredUse case
strict0.90premise0.85yesKYC, fraud prevention, compliance
shipping0.70street0.50noPhysical delivery, e-commerce
standard0.55street0.45noGeneral verification (default)
permissive0.30locality0.30noLead capture, marketing

​
Choosing a policy

Requires premise-level address matching (0.90 confidence), high email confidence (0.85), and phone verification. Use for financial services, identity verification, and any flow where false positives are costly.
Requires street-level matching (0.70 confidence) and moderate email confidence (0.50). Phone is optional. Use for e-commerce checkout, delivery address validation, and logistics.
The default policy. Requires street-level matching (0.55 confidence) and basic email confidence (0.45). Suitable for most use cases where you want verification without being overly restrictive.
Accepts locality-level matching (0.30 confidence) with minimal thresholds. Use for lead forms, newsletter signups, and scenarios where you want to capture data even if it’s imprecise.

​
Using a policy

​
CLI

lqt verify -a "10 Downing St, London, GB" --policy shipping -o json

​
Environment variable

export LOQATE_POLICY=shipping
lqt verify -a "10 Downing St, London, GB" -o json

​
Policy resolution order

When multiple policy sources are present, Reach resolves in this order:
  1. --policy-file flag (custom policy JSON file)
  2. --policy flag (named built-in policy)
  3. LOQATE_POLICY environment variable
  4. .loqate-policy.json file in the current directory
  5. standard (default)

​
Custom policies

Create a JSON file to define your own thresholds:
custom-policy.json
{
  "name": "my-ecommerce-policy",
  "description": "Balanced policy for e-commerce checkout",
  "address": {
    "min_confidence": 0.65,
    "min_match_level": "street",
    "reject_verification_status": ["U", "R"]
  },
  "email": {
    "min_confidence": 0.50,
    "allow_catch_all": true,
    "reject_disposable": true
  },
  "phone": {
    "min_confidence": 0.40,
    "required": false
  }
}

​
Custom policy fields

​
Address

FieldTypeDescription
min_confidencenumberMinimum confidence score (0–1) to accept
min_match_levelstringMinimum match level: premise, street, locality, administrative_area, country
reject_verification_statusarrayVerification statuses to auto-reject (e.g., ["U", "R"])

​
Email

FieldTypeDescription
min_confidencenumberMinimum confidence score (0–1) to accept
allow_catch_allbooleanWhether to accept catch-all email domains
reject_disposablebooleanWhether to reject disposable/temporary email domains

​
Phone

FieldTypeDescription
min_confidencenumberMinimum confidence score (0–1) to accept
requiredbooleanWhether phone verification is mandatory

​
Validate a custom policy

lqt policy validate custom-policy.json

​
Use a custom policy

lqt verify -a "10 Downing St, London, GB" --policy-file custom-policy.json -o json

​
Register via MCP

In an MCP session, use the set_policy tool to register a custom policy for the current session. This is useful when your agent needs to switch policies based on context.