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

Search docs

Search documentation…

  1. Home
  2. /Operate
  3. /Monitoring & support

Monitoring & support

What to alert on, requestId correlation, and escalation.

TopicsOperate

What to watch in production, how to correlate failures, how to escalate, and what Avrix will (and will not) promise in public docs.

Support#

ChannelUse
support@avrix.ioProduction incidents, integration blockers, certification evidence hand-off
Your Avrix partner / pilot contactPilots and commercial onboarding — prefer this when you have a named contact

Never paste API key secrets, webhook signing secrets, or game-key plaintext into tickets. Include requestId (see below).

Status and incidents#

There is no single public status URL documented for Seller API partners. Ask your Avrix contact for the current status channel used for your program (email list, Slack, or similar).

For an active incident, open support with the correlation fields below. Response expectations and any contractual SLA are defined in your commercial agreement — this guide does not invent uptime or response-time SLAs.

Planned maintenance#

Planned maintenance is communicated via your partner contact and/or email when scheduled. Design clients for transient 5xx with exponential backoff and the same Idempotency-Key on retries. See Idempotency and Error playbook.

What to watch#

SignalWhy
POST /orders success rateBuyer-facing fulfilment health
409 NO_AVAILABLE_KEYS after chargePreview / hold / stock race — refund path must work
402 / payment-related denials (if applicable to your flow)Commercial or entitlement gate spike
422 spikes (CATALOG_PRICE_MISMATCH, territory, evidence)Catalog drift or missing production IOC fields
429 rateSync too aggressive or tier too low
Idempotency mismatches / in-flightClient retry bugs
Webhook delivery failure rateEndpoint down, signature bugs, slow handlers
Pull velocity anomaliesCompromised key or runaway job
Reconciliation drift (GET /orders vs local OMS)Missed webhooks or unknown-outcome gaps
Orphan PSP captures (no Avrix aggregate)Unknown-outcome gap in checkout

Alert on sustained error budgets, not single sandbox noise.

Recommended partner alerts#

Prioritise these in production:

  1. Webhook delivery failures — sustained non-2xx or auto-disable on your endpoint
  2. 402 / 409 rate — especially NO_AVAILABLE_KEYS after a successful PSP charge
  3. Reconciliation drift — local paid orders missing from GET /orders (or the reverse)
  4. 429 spikes — rate-limit bursts that indicate a runaway sync or missing ETag / backoff

Request correlation#

Every error response includes a requestId. Responses may also echo X-Request-Id when you sent one.

When opening a ticket, include:

FieldExample
requestId / X-Request-Idreq_01J8XYZ...
orderReferencestore-order-10432
Approximate UTC timestamp2026-08-05T09:14:22Z
Environmentsandbox / production
API key id (not the secret)From Console → Settings → Integrations → API Keys
Route + HTTP status + error codePOST /orders → 409 NO_AVAILABLE_KEYS

Optional: GET /api/seller/v1/requests/{requestId} for a redacted trace (no plaintext keys).

Keep requestId in your structured logs for every Seller API call and every webhook handler invocation you correlate to an Avrix delivery. Retention of those log lines is your policy; Avrix keeps commercial evidence and delivery history under the schedules in Data handling and your DPA — not as a substitute for your own logs.

Escalation path#

  1. Self-serve — check GET /whoami, deliveries list, GET /orders?orderReference=, catalog changes.
  2. Replay — webhook delivery replay for missed push events (metadata only).
  3. Support — email support@avrix.io (or your partner contact) with the correlation table above.
  4. Security incident — revoke keys first (Security / Authentication), then escalate.

Compliance and transport#

  • TLS: Seller API traffic is HTTPS only. Do not send credentials over cleartext.
  • Data roles and retention: Data handling.
  • Compliance package (SOC reports, questionnaires, etc.): ask Avrix for the current package under your commercial / DPA process — do not assume a specific certification from public docs alone.

Health and introspection endpoints#

CheckRoute
Platform upGET /api/seller/v1/health (no auth)
Key / company / capabilitiesGET /api/seller/v1/whoami
Integration readinesswhoami.integrationReadiness
Egress IP discoveryGET /api/seller/v1/whoami-ip
Usage summaryGET /api/seller/v1/usage
Activity feedGET /api/seller/v1/activity
Redacted request traceGET /api/seller/v1/requests/{requestId}

Use usage and activity for capacity and ops dashboards. Use requests/{requestId} when correlating a support ticket — traces are redacted and never include plaintext keys.

Related#

  • Go-live
  • Partner runbook
  • Data handling
  • Reconciliation
  • Polling and reconciliation
  • Error playbook
  • Security

What links here

Published guides that link to this page.

  • Deployment targetsServerless, containers, and workers — cold starts, secrets, and webhook timeouts.
  • Go-liveProduction prerequisites, cutover procedure, and rollback.
  • Partner runbookSandbox vs production, strict mode, and operational checks.
  • SandboxTest environments, magic SKUs, and auth triage.
  • Sandbox to productionReadiness checklist and cutover steps before your first live order.
  • TroubleshootingSymptom-first trees for auth, empty catalog, inventory, idempotency, and webhooks.
PreviousIP allowlistNextData handling

Need help with this page?

Contact support

AI tools

  • Ask ChatGPT
  • Ask Claude

On this page

  • Support
  • Status and incidents
  • Planned maintenance
  • What to watch
  • Recommended partner alerts
  • Request correlation
  • Escalation path
  • Compliance and transport
  • Health and introspection endpoints
  • Related

Related pages

  • Partner runbookSandbox vs production, strict mode, and operational checks.
  • Error referenceHTTP statuses, canonical error codes, and recovery actions.
  • WebhooksSigned delivery, event types, retries, and verification.
  • Rate limitsPer-tier request ceilings, headers, and Retry-After guidance.
  • Go-liveProduction prerequisites, cutover procedure, and rollback.