Territory enforcement

Avrix enforces regional SKU territory and declared sales country on production API-key orders before keys are pulled. Buyer IP geo / VPN verification defaults to enforce on production keys. Sandbox keys stay off. Discover the live posture via GET /whoami:

Reserve and hold now run the same territory and geo gates as preview (API-model allocations) so a region-mismatched buyer fails before payment.

Whatever the phase, the country the gate resolved from the buyer IP is persisted next to the declared salesCountryCode on every API-model sale and pull row: GET /finance/api-sales, GET /finance/statements lines and GET /transactions return detectedCountryCode, countryMismatch and warnings: ["COUNTRY_MISMATCH"], and the api-sales CSV carries customerRegionCode, detectedCountryCode, warning columns. In monitor mode this is the fraud signal for a sale that went through with a geoWarning; the raw IP is never returned.

curl -s -X GET "https://api.avrix.io/api/seller/v1/availability?skuCode=SANDBOX-ALWAYS-001&quantity=1&country=US" \
  -H "Authorization: Bearer $AVRIX_API_KEY"

Market region locks as VPN-proof only when capabilities.consumerGeoEnforcementEnabled is true. Territory allowlists and catalog list-price checks are always enforced on production keys. Sandbox keys never enable IP-country or VPN/hosting checks.

1. SKU territory (always) — salesCountryCode / preview countryCode must be in the publisher region country pack for that SKU (minus release exclusions).
2. Catalog list price (always) — expectedUnitPriceCents must match POST /orders/preview for the same country.
3. Buyer IP shape (when geo enforcement is on) — production keys require integrationOrderContext.consumerIp (public routable IPv4/6); private/reserved IPs are always rejected when supplied.
4. Geo cross-check (when geo enforcement is on) — IP-derived country must equal salesCountryCode.
5. VPN / hosting block (when geo enforcement is on and anonymous-IP data is loaded) — VPN, hosting, Tor, and public proxy IPs are rejected.
6. Restricted jurisdiction (always) — some locations are not available for access or sale (LOCATION_BLOCKED on your API source IP; COUNTRY_RESTRICTED on the sales country or buyer IP).
7. Checkout-page confirmation, standard on production connections (GET /allocations.consumerGeoAttestRequired, also whoami.capabilities.consumerGeoAttestRequired). Call POST /geo/attest, load pixelUrl in the buyer browser, and send consumerGeoAttestId on preview/hold/reserve/commit. Completing the pixel from your store server is rejected (CONSUMER_IP_INVALID).

When geo enforcement is off, a supplied malformed IP is still rejected. Sandbox / non-production keys never enable IP-country or VPN/hosting checks, and never require checkout-page confirmation.

1. Discover territory — GET /products/{id} → releases[].allowedCountries; GET /regions → allowedCountries per region code.
2. Availability first — GET /availability with the buyer's country at product-page time and hide the buy button when the SKU is not sellable there.
3. Preview — POST /orders/preview with countryCode and the real buyer IP at cart time.
4. Reserve / hold — send the same countryCode plus integrationOrderContext.consumerIp before charging. Under enforcement, a missing IP returns CONSUMER_IP_REQUIRED.
5. Order — include both fields in integrationOrderContext:

{
  "expectedUnitPriceCents": 450000,
  "integrationOrderContext": {
    "schemaVersion": 1,
    "salesCountryCode": "JP",
    "consumerIp": "203.0.113.42",
    "currencyCode": "JPY",
    "salesPriceGrossMinor": 598000
  }
}

1. Capture the end-buyer public IP — see Which IP to send.
2. Re-preview on CATALOG_PRICE_MISMATCH, TERRITORY_*, or CONSUMER_GEO_MISMATCH.
3. Discover posture — GET /whoami → consumerGeoEnforcementEnabled / consumerGeoMonitorEnabled. During monitor, treat geoWarning in 200 responses as a would-be 422.

Send the end-buyer's public IPv4 or IPv6, not your store backend's egress address.

• Read it from your CDN or load-balancer headers after you trust the hop (for example CF-Connecting-IP on Cloudflare, or the first public address in X-Forwarded-For behind nginx).
• Do not forward an unverified client-supplied header.
• Sending your server or NAT egress IP will usually trip CONSUMER_IP_HIGH_RISK (hosting range). Prompt the buyer to disable VPN when you receive that code.

Sandbox keys can exercise the same codes without geo data using 203.0.113.66 (CONSUMER_GEO_MISMATCH) and 203.0.113.99 (CONSUMER_IP_HIGH_RISK). See Sandbox.

Sale territory answers "may I sell here?"; activation territory answers "will the delivered key actually redeem there?" — vendors can stock region-locked keys for a SKU whose sale territory is broader. The API exposes the guaranteed activation set per SKU, computed across all inventory batches (a mixed pool of worldwide and region-locked batches reports the most restrictive intersection, because your pull may be served from any batch):

• GET /products/{productId} — each SKU carries activation: { type, countries } where type is worldwide, region_locked, or unknown (no unarchived batch metadata) and countries is the guaranteed ISO 3166-1 alpha-2 list (null when worldwide or unknown).
• GET /allocations — every row carries the same activation block.
• POST /orders/preview — lines[].activation, plus the advisory warning ACTIVATION_REGION_MISMATCH when your countryCode falls outside the guaranteed set and whoami.capabilities.activationPolicy is warn (the default).
• POST /orders, POST /keys/pull, POST /orders/{orderId}/fulfill — the success body carries the same activation block next to the delivered keys (also on pre-order acceptances), so "activates in" can be shown at delivery time without a second lookup. It is resolved after the pull commits; if inventory metadata cannot be read at that moment the field degrades to { "type": "unknown", "countries": null } rather than failing a delivered order.

activationPolicy is also on GET /integration/status. Modes:

Missing countryCode is never an activation 422 (sale territory remains a separate gate).

Discover countries and region packs the platform exposes:

Use these to validate buyer-country pickers and map storefront locales to ISO country codes before preview. Territory allow/deny for a SKU still comes from preview / commit errors and allocation readiness — the regions catalog is reference data, not a sellability gate by itself.

• Declared salesCountryCode remains authoritative for territory allowlists even when geo is off.
• When anonymous-IP data is unavailable, VPN/hosting blocks are skipped but country cross-check still runs when country geo data is present.
• Sandbox / non-production keys never enable IP-country or VPN/hosting layers. Shared sandbox catalog magic IPs (203.0.113.66, 203.0.113.99) still return the matching CONSUMER_* codes so integrators can test.