Location Targeting
AON location targeting is a Partner Offer-side declaration. It uses canonical location ids to express where a supply Offer may be eligible. It is separate from both Location Registry lookup and the public Query v1.0 request.
Offer-side geographic targeting
A Partner Offer artifact can declare up to ten targeting[] rules. Geographic
rules use geo.include and geo.exclude:
{
"targeting": [
{
"geo": {
"include": [{"location_id": "2840"}],
"exclude": [{"location_id": "21180"}]
}
}
]
}Each entry is a closed object containing one numeric-string location_id.
Every id must exist in the Full Location Catalog pinned by Protocol v1.0;
numeric syntax alone is not enough. A location matches itself or a descendant,
and geo.exclude wins over geo.include.
targeting is Partner-authored supply configuration. AON evaluates it before
ranking and removes it from the public Offer projection returned to a
Developer.
Query v1.0 boundary
The current Query v1.0 request accepts structured intent, category constraints,
bounded platform and session context, and response controls. Its context
object is closed and does not define user_profile or another viewer-location
field. Do not send context.user_profile.location_ids, coordinates, country,
or a Location Search result in the Query body.
A location_ids chain returned by Location Search or a schema helper is
registry ancestry data. It is not a Query v1.0 input. Deployment-owned
eligibility context and runtime policy remain outside the portable public
Query contract.
Location Search and registry lookup
Location Search remains a public lookup and normalization API with three routes:
GET /v1/locations/searchsearches by name, country, parent, subdivision code, and supported catalog filters.GET /v1/locations/resolvenormalizes external location signals into AON ids and candidate records.GET /v1/locations/{location_id}returns one registry record and its self-to-root ancestry chain.
The default LEGACY catalog exposes the compatible COUNTRY, REGION, and
CITY levels. Explicit FULL search preserves the source target type and
verified hierarchy instead of relabeling deeper target types. Use the
Location Search API for complete parameters, response
fields, catalog differences, and examples.
Static Registry
Use the static AON Location Registry when you need deterministic offline lookup for the compatible three-level catalog.
Each entry contains location_id, name, canonical_name, country_code,
target_type, aon_level, and parent_location_id. The registry does not
publish precomputed ancestor caches; callers derive chains from parent links.
Migration Helpers
The schema repo includes helpers for registry lookup, ancestry inspection, and migrating legacy Partner Offer targeting:
import {
buildLocationChain,
cloudflareHeadersToLocationContext,
countryCodeToLocationId,
googleCloudHeadersToLocationContext,
legacyCountryGeoToLocationGeo,
subdivisionCodeToLocationId,
} from "@agentoffernetwork/schema/helpers/location-helpers.mjs"
countryCodeToLocationId("US")
// "2840"
legacyCountryGeoToLocationGeo(["US", "SG"])
// [{ location_id: "2840" }, { location_id: "2702" }]
// Suitable for a Partner Offer targeting[].geo include or exclude list.
buildLocationChain("1014221")
// ["1014221", "21137", "2840"]
subdivisionCodeToLocationId("US-CA")
// "21137"
cloudflareHeadersToLocationContext({
"cf-ipcountry": "US",
"cf-region-code": "CA",
"cf-ipcity": "San Francisco",
}).location_ids
// ["1014221", "21137", "2840"]
googleCloudHeadersToLocationContext({
client_region: "US",
client_region_subdivision: "USCA",
client_city: "San Francisco",
}).location_ids
// ["1014221", "21137", "2840"]The header helpers normalize external signals and return lookup data for
deployment-owned workflows. Their location_ids arrays are not fields to copy
into a public Query v1.0 request.
External Codes
AON accepts external location codes only as lookup aliases. Integrations that
already store ISO 3166-2 values such as US-CA, Cloudflare
cf-ipcountry + cf-region-code, or Google Cloud client_region +
client_region_subdivision can resolve them before persisting a canonical id
or preparing Partner Offer geo targeting.
External codes are not Partner Offer target ids or public Query fields. Resolve them first, then use the returned AON id only in the workflow that owns it.
Related references
- Location Search API for interactive lookup, normalization, and ancestry data.
- Partner Offer Schema for the supply carrier that owns
targeting. - Offer Query API for the current public Query request and its declared fields.
- Category Taxonomy for explicit Query category constraints.
- Protocol source guide for canonical source ownership.