Glossary

Canonical Seller API terms. Prefer these spellings in integration code and runbooks. The render pipeline auto-links these terms in other guides — keep headings stable.

Jump to: A · B · C · D · E · F · G · H · I · K · L · M · O · P · Q · R · S · T · V · W

The storefront / content seller company integrating the Seller API.

See Overview.

The content owner (studio / publisher) that owns products and inventory. Use vendor in technical prose — not “publisher” as an API role name.

See How Avrix works.

A vendor company connected to you via an active agreement. Listed by GET /partners.

See Authentication.

Stock-keeping unit — the sellable product variant (platform, edition, region). Identified by skuId or skuCode (e.g. SANDBOX-ALWAYS-001).

See Catalog and allocations.

Business Master Agreement — commercial terms binding vendor and seller. First of the four sellability gates.

See How Avrix works and Pricing view and BMA authority.

Vendor permission for a seller to see / order a SKU in catalog scope. Share without allocation is not enough to sell.

See Catalog and allocations and Sellable SKU readiness.

Capacity granted by a vendor to a seller for a SKU. GET /allocations with sellable: true is authoritative for checkout.

See Catalog and allocations.

The capacity record behind GET /allocations (grant id, remaining units, wholesale price). Hot paths read grants, not legacy allocation tables.

See Catalog and allocations.

A SKU you may commit right now — all four gates open and GET /allocations reports sellable: true. Catalog presence alone is not sellable.

See Sellable SKU readiness.

Products and SKUs visible to you via shares. Browse via /products, /catalog/snapshot, /catalog/changes.

See Catalog and allocations and Product field matrix.

Product lifecycle dimension that gates catalog visibility (for example available). Non-live phases are excluded from sellable browse.

See Sellable SKU readiness.

Commercial open/closed dimension on releases. Checkout rejects products that are not open for trade.

See Sellable SKU readiness.

Geographic rules for where a SKU may be sold; driven by buyer salesCountryCode / countryCode (e.g. US).

See Territory enforcement and Where a sale is allowed.

Countries the live API Agreement gives this Content Seller. Changing the grant is a countersigned amendment.

See Where a sale is allowed.

Countries and currencies the Content Seller declared they sell in. An undeclared country is refused even when it was granted.

See Where a sale is allowed.

The catalog region on the SKU. Every SKU on the same region shares that country set.

See Where a sale is allowed.

A Content Owner removes a granted country for one Content Seller, for every title under that Agreement. A lock can only remove a country.

See Where a sale is allowed.

A Content Owner removes a covered country for one title, for every partner. Leave it empty unless that title must be stricter than the deal.

See Where a sale is allowed.

Full catalog export from GET /catalog/snapshot for bootstrap sync. Pair with allocations for sellability.

See Catalog and allocations.

A delete/remove marker in GET /catalog/changes?since= so clients can drop SKUs that left the share.

See Catalog and allocations.

Commit-time stock / sellability check (GET /availability). List expand fields are advisory.

See Order preview.

POST /orders/preview — read-only fulfilability and price confirmation (canFulfill, unitPriceCents).

See Order preview.

A committed sale / reservation created via POST /orders (or reserve/commit). Consumes capacity when fulfilled.

See Creating orders and Order lifecycle.

Your immutable business identifier for the sale (e.g. store-order-10432). Required on create order; used for lookup and finance. Distinct from Idempotency-Key.

See Creating orders and Idempotency.

HTTP header that makes a write retry-safe for 24 hours when the body matches. Does not replace orderReference as business identity.

See Idempotency.

Soft stock hold (POST /orders/hold) while the buyer pays; pass checkoutHoldId into POST /orders when enabled. Not the same as hot-drop reservation.

See Checkout holds.

Hot-drop slot lock (POST /orders/reserve → POST /orders/commit) with a short TTL. Used only when the allocation is in hot-drop mode.

See Hot drop.

High-contention allocation mode that requires reserve → commit (or extend) instead of a plain POST /orders.

See Hot drop.

Optional signed token from preview that binds the wholesale unit price through payment and commit.

See Order preview.

Returning the original fulfilment for a repeated orderReference instead of selling again. Partial prior fulfilment cannot be topped up.

See Idempotency and Order lifecycle.

Partner-declared checkout evidence (country, currency, retail gross, payment-processor reference, consumer IP, …) attached to commercial mutations.

See Order context.

Catalog/wholesale price Avrix validates on commit — echo preview’s unitPriceCents as expectedUnitPriceCents.

See Order preview and Pricing view and BMA authority.

Delivery of entitlements (plaintext keys) after a successful order.

See Fulfilment and keys.

Digital game code plaintext. Returned only on mutation responses as a string in keys[]; never on GET /orders or webhooks.

See Fulfilment and keys.

Parallel UUID array on order success (keyIds[i] matches keys[i]). Required for refunds and returns — persist with the plaintext.

See Key return policy.

deliveryMode on order responses. The public Seller API delivers keys with "key" (plaintext codes; the default).

See Fulfilment and keys.

Refund / return path that takes fulfilled keys out of circulation via POST /refunds or POST /keys/return using keyIds.

See Key return policy.

Shared test environment with magic SKUs and test keys. Keys prefixed like avrix_sk_sbx_… on production hosts.

See Sandbox and Environments.

Live agreements, real keys, full commercial evidence enforcement.

See Sandbox to production and Go-live.

Deterministic sandbox SKU codes (for example SANDBOX-ALWAYS-001) for golden-path and negative-path tests.

See Sandbox.

Signed HTTPS push of lifecycle events. At-least-once; dedupe on eventId.

See Webhooks and Event reference.

Stable id on every webhook delivery (eventId). Deduplicate before applying side effects.

See Webhooks.

Permission string on an API key (for example seller:orders:write). Empty scopes are denied.

See Scope matrix.

Short-lived opaque Bearer (avrix_oat_*) minted via OAuth2 client credentials and mapped to an API key. Same scopes, environment, and IP rules as the underlying key.

See OAuth tokens.

API key created by POST /keys from a parent key. Scopes are the server default set intersected with the parent’s scopes; environment and expiry inherit from the parent.

See API key management.

Platform-event promotion a vendor shared with your seller company. Accept or decline via the promotions API; discount tables are available after accept.

See Promotions.

Vendor-specific promotion (not a platform event) that your seller company can approve or reject.

See Promotions.

• Overview
• How Avrix works
• Idempotency
• Catalog and allocations