AvrixDocumentation
API referenceStatusAvrix.ioConsole
Seller API

Welcome

  • Home
  • Getting started
  • Topic index
  • Glossary

Get started

  • Overview
  • How Avrix works
  • Architecture patterns
  • Quickstart
  • Integration tutorial
  • Authentication
  • OAuth tokens
  • Environments
  • Sandbox

Connect a partner

  • Partner onboarding
  • Sellable SKU readiness
  • Territory enforcement
  • AI assistants (MCP)
  • Connect your AI client
  • Sign-in and permissions

Catalog

  • Catalog & allocations
  • Product field matrix
  • Pricing authority
  • Currency and FX
  • Promotions
  • Caching & fairness

Sell an order

  • Store integration profiles
  • Order preview
  • Creating orders
  • Idempotency
  • Order context
  • Checkout holds
  • Hot drop
  • Fulfillment & keys
  • Keyless fulfilment
  • Order lifecycle
  • Refunds & returns

Stay in sync

  • Webhooks
  • Event reference
  • Polling & reconciliation
  • Reconciliation
  • Finance & settlement

Operate

  • Error reference
  • Troubleshooting
  • Key recovery
  • Rate limits
  • Security
  • Secrets & config
  • API key management
  • IP allowlist
  • Monitoring & support
  • Data handling
  • Partner runbook

Go live

  • Testing
  • Certification
  • Integration checklist
  • Sandbox to production
  • Go-live
  • Deployment targets

Reference

  • Integration recipes
  • Scope matrix
  • Commerce platforms
  • API clients
  • Client & helpers
  • Versioning
  • Changelog
  • FAQ
  • API reference
  1. Home
  2. /Get started
  3. /Architecture patterns

Architecture patterns

Where Seller API fits in your stack — service layer, workers, and server-only keys.

TopicsGet started

Where the Seller API belongs in your stack — and where it must never appear.

What this covers#

Service-layer placement, common topologies (monolith, microservice, event-driven), commerce-platform hooks, and the hard rule that Seller API credentials stay on the server. Avrix is not a replacement for Steam, Epic, or other platform store APIs.

Hard rule: server-side only#

Your Seller API key authenticates your backend to Avrix. Never put the key in:

  • Browser JavaScript or storefront themes
  • Mobile or desktop app clients
  • Public CDN assets or client-side SDKs

The storefront talks to your API; your API talks to Avrix.

Placement in your app#

Typical layers:

LayerResponsibility
Controller / routeAccept checkout events from your store; validate session
ServicePreview → charge at your PSP → create order; map errors
Worker / queueWebhook verification, retries, catalog sync, reconciliation

Keep Avrix HTTP calls inside the service (or a dedicated Avrix client module). Controllers should not assemble Bearer headers or invent idempotency keys ad hoc.

Diagram
BuyerStorefrontYour APIPSPSeller APIWebhook worker
BuyerStorefrontYour APIPSPSeller APIWebhook worker

Topology choices#

Monolith#

One app process owns catalog sync, checkout, and webhook handlers. Fine for most keyshops. Use a shared HTTP client and a single secrets source.

Microservice#

Split “catalog sync”, “checkout / orders”, and “webhooks” if teams own them separately. Share the same sandbox vs production key policy; do not mint a key per microservice unless scopes require it.

Event-driven#

Emit internal events after PSP success (OrderPaid) and after Avrix fulfilment (OrderFulfilled). Consumers update entitlement or email delivery. Always verify Avrix webhook signatures before side effects — see Webhooks.

Commerce stacks#

StackTypical hook
Laravel / Magento / WooCommerceServer plugin or module after payment success
ShopifyApp backend / webhook worker — not theme Liquid
Spring / .NET publisher portalsService layer behind authenticated admin APIs

Steam / Epic boundary#

Platform store APIs (Steamworks, Epic Online Services, and similar) manage their storefronts, entitlements, and ownership. Avrix Seller API manages your allocated inventory and fulfilment for stores you operate. Do not expect Avrix endpoints to create Steam packages or Epic offers; integrate those platforms on their own contracts, and use Avrix where you sell keys through your commerce stack.

Common mistakes#

  • Calling Avrix from checkout JavaScript “for speed”.
  • Sharing one production key across unrelated environments.
  • Treating webhook delivery as optional and never reconciling — see Polling and reconciliation.

Next steps#

  • API clients — language-specific HTTP setup
  • Commerce platforms — Shopify, Woo, Magento, keyshops
  • Store integration profiles — Profile A/B/C

What links here

Published guides that link to this page.

  • Commerce platformsShopify, WooCommerce, Magento, keyshops, game backends, and platform-store boundaries.
  • FAQShort answers on sellability, keys vs keyless, idempotency, webhooks, and sandbox.
  • Client & helpersGenerate a typed client from OpenAPI and implement production HTTP patterns.
PreviousHow Avrix worksNextQuickstart

Need help with this page?

Contact support

AI tools

  • Ask ChatGPT
  • Ask Claude

On this page

  • What this covers
  • Hard rule: server-side only
  • Placement in your app
  • Topology choices
  • Monolith
  • Microservice
  • Event-driven
  • Commerce stacks
  • Steam / Epic boundary
  • Common mistakes
  • Next steps

Search docs

Search documentation…

Related pages

  • Commerce platformsShopify, WooCommerce, Magento, keyshops, game backends, and platform-store boundaries.
  • API clientsProduction HTTP client patterns per language — config, reuse, and retries.
  • Store integration profilesProfile A/B/C checkout patterns — preview, hold, and hot-drop.
  • SecurityCredential handling, rotation, allowlisting, and webhook safety.
  • Seller API overviewWhat the Seller API does, who it is for, and the golden-path integration shape.