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. /Go live
  3. /Certification

Certification

Required sandbox test cases and evidence format before production access.

TopicsGo live

Avrix grants production access against evidence that your integration handles failure paths — not only the happy path. Run every case in sandbox, capture requestId and the response, and keep a one-line note of how your system behaved.

Use Environments for host and key rules, and Go-live for the cutover checklist after certification passes.

Evidence format#

For each case record:

  1. Case number and name
  2. requestId from the response (or X-Request-Id)
  3. HTTP status and error code if any
  4. One line describing your system's behaviour (refund issued, webhook deduped, catalog delisted, …)

A test-suite log or structured log excerpt is enough. The goal is demonstrable behaviour, not a formal document.

Required test cases#

Catalog#

#CaseExpectedFixture
1Cold-start syncFull sellable catalog persisted with cursor—
2Incremental syncDeltas applied, cursor advanced—
3Tombstone handlingRemoved SKU delisted from storefront—
4Allocation mergeAllocation-only SKUs present in sellable set—
5Unsellable SKU excludedShared-but-unallocated SKU has no buy buttonSANDBOX-NOALLOC-001
6Non-live product excludedNot offered for saleSANDBOX-LIFECYCLE-001

Case 4 verifies you did not build the catalog from /products alone. See Catalog and allocations.

Orders#

#CaseExpectedFixture
7Happy pathOrder fulfilled; key delivered and persistedSANDBOX-ALWAYS-001
8Preview gatingNo charge when canFulfill is false—
9Sold out after payment409; buyer refunded at your PSPSANDBOX-NOKEYS-001
10Price driftMismatch handled; no silent repricing—
11Territory rejectionHandled before or at checkout—
12Idempotent replaySame key + same body → original response, one fulfilment—
13Idempotency conflictSame key + different body → IDEMPOTENCY_KEY_MISMATCH—
14Unknown outcomeTimeout → replay same key; no double charge, no double pull—

Case 14 is the highest-value test. Simulate by killing the connection mid-request. See Order lifecycle.

Fulfilment#

#CaseExpected
15Key persistenceKey written to durable storage before responding to the buyer
16Key non-recoveryConfirm GET /orders never returns plaintext keys

Webhooks#

#CaseExpected
17Valid signatureAccepted and processed
18Invalid signatureRejected — deliberately corrupt one
19Stale timestampRejected beyond 300 seconds
20Duplicate deliverySecond delivery ignored via event id
21Webhook before responseHandler tolerates an unrecorded order
22Secret rotationBoth secrets accepted during overlap window

Case 18 is the one integrations most often skip. An endpoint that accepts every signature is worse than no verification.

Refunds#

#CaseExpected
23Key returnKeys quarantined using persisted keyIds from the order response
24Refund recordedRefund status retrievable via GET /refunds

Operations#

#CaseExpected
25Rate limit429 handled with Retry-After
26Server error5xx retried with backoff and the same idempotency key
27Request correlationrequestId logged on every error
28ReconciliationScheduled job compares local orders against GET /orders

Approval#

Submit your evidence package (the 28 cases above, with request ids and timestamps) to your Avrix partner contact or support@avrix.io.

After review, Avrix enables production Seller API access on your company. Until that happens, production keys on api.avrix.io receive 403 PRODUCTION_ACCESS_NOT_APPROVED even after you have signed the API Revenue Share Channel Terms and created a production key. Sandbox continues to work for regression testing.

Typical review turnaround is measured in business days — ask your contact for the current SLA when you schedule cutover. If a case fails review, fix it and resubmit only the failed rows with fresh requestIds.

Related#

  • Integration checklist
  • Go-live
  • Sandbox to production
  • Error reference

What links here

Published guides that link to this page.

  • EnvironmentsSandbox and production share api.avrix.io; key prefixes, fixtures, and behavioral differences.
  • Error referenceHTTP statuses, canonical error codes, and recovery actions.
  • Go-liveProduction prerequisites, cutover procedure, and rollback.
  • Integration checklistPhase-by-phase tracker from evaluation through post-launch.
  • Seller API overviewWhat the Seller API does, who it is for, and the golden-path integration shape.
  • Sandbox to productionReadiness checklist and cutover steps before your first live order.
  • TestingSandbox magic SKUs, mocks, contract tests, and webhook verification.
PreviousTestingNextIntegration checklist

Need help with this page?

Contact support

AI tools

  • Ask ChatGPT
  • Ask Claude

On this page

  • Evidence format
  • Required test cases
  • Catalog
  • Orders
  • Fulfilment
  • Webhooks
  • Refunds
  • Operations
  • Approval
  • Related

Search docs

Search documentation…

Related pages

  • Integration checklistPhase-by-phase tracker from evaluation through post-launch.
  • Go-liveProduction prerequisites, cutover procedure, and rollback.
  • Sandbox to productionReadiness checklist and cutover steps before your first live order.
  • Error referenceHTTP statuses, canonical error codes, and recovery actions.
  • WebhooksSigned delivery, event types, retries, and verification.