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. /Stay in sync
  3. /Reconciliation

Reconciliation

Tie storefront orders to Avrix aggregates and resolve discrepancies.

TopicsStay in sync

Tie your storefront orders to Avrix records so uncertain outcomes, missed webhooks, and support tickets resolve from facts — not guesswork.

Example#

curl -s -X GET "https://api.avrix.io/api/seller/v1/orders?orderReference=store-order-10432" \
  -H "Authorization: Bearer $AVRIX_API_KEY"

What to store locally#

For every commercial attempt, persist at least:

FieldSource
orderReferenceYour checkout / OMS id
Idempotency-KeyGenerated before POST /orders
Preview unit price / commitment tokenPOST /orders/preview
Avrix response type and identifiersPOST /orders response
keyIdsPOST /orders response (authoritative)
PSP payment referenceYour payment processor
Last known webhook event idDelivery headers

Canonical reads#

NeedCall
Everything settled, one cursorGET /api/seller/v1/activity?from=…&to=… (sale / refund / chargeback / pull / reveal with signed stockMovement, promo, counterparty, economics)
Order by your referenceGET /api/seller/v1/orders?orderReference=store-order-10432
Order by Avrix readable idGET /api/seller/v1/orders?orderReadableId=ord_…
Key-pull historyGET /api/seller/v1/transactions
Missed webhook deliveriesGET /api/seller/v1/webhooks/{id}/deliveries (+ replay)
Catalog driftGET /api/seller/v1/catalog/changes?since= + /catalog/checksum
Finance overviewGET /api/seller/v1/finance/summary
Sale linesGET /api/seller/v1/finance/api-sales
InvoicesGET /api/seller/v1/finance/invoices
Refund / chargeback statusGET /api/seller/v1/refunds

GET /orders returns aggregates (fulfilled[], preOrderActive[]) and never returns plaintext keys. Design your recovery paths accordingly.

Recommended job (orders)#

Run on a schedule (for example every 5–15 minutes):

  1. Select local orders in an uncertain or awaiting-webhook state older than your timeout.
  2. For each, call GET /orders?orderReference=….
  3. If Avrix shows fulfilment and you lack keys locally — escalate; keys are not recoverable from GET. Prefer webhook replay / delivery audit, then support with requestId.
  4. If Avrix has no order and your PSP captured funds — do not create a second order with a new idempotency key until you have replayed the original key and body. See Idempotency and Order lifecycle.
  5. If Avrix fulfilled but your PSP failed — return keys / refund path and refund at your PSP as your policy requires.

Finance reconciliation procedure#

Run on a settlement-relevant cadence (daily or per your agreement — cadence is agreement-dependent):

  1. Pull operational truth: for each local commercial day (or window), list GET /orders (and/or GET /transactions) keyed by orderReference.
  2. Pull the settlement feed: GET /activity?from=…&to=… (paginate with cursor; format=csv for spreadsheets). Sum stockMovement per orderReference — a delivered-then-refunded key nets to zero. GET /finance/api-sales remains available as the sale-line view.
  3. Match rows on orderReference / keyId. Investigate orphans (Avrix sale without local order, or local capture without Avrix sale).
  4. Check GET /finance/summary for outstanding balances and report posture; pull GET /finance/invoices when invoice intake is part of your close.
  5. Align refunds and chargebacks: GET /refunds vs your PSP dispute ledger; quarantine via POST /refunds when Avrix has not yet been told.
  6. Do not invent payout dates from this API — settlement timing follows your commercial agreement.

See Finance and settlement.

Related#

  • Polling and reconciliation
  • Order context
  • Error reference

What links here

Published guides that link to this page.

  • Finance & settlementWhat is recorded, settled, and invoiced after API sales.
  • Monitoring & supportWhat to alert on, requestId correlation, and escalation.
  • Polling & reconciliationRecover from missed webhooks with deliveries replay and order reads.
PreviousPolling & reconciliationNextFinance & settlement

Need help with this page?

Contact support

AI tools

  • Ask ChatGPT
  • Ask Claude

On this page

  • Example
  • What to store locally
  • Canonical reads
  • Recommended job (orders)
  • Finance reconciliation procedure
  • Related

Related pages

  • Finance & settlementWhat is recorded, settled, and invoiced after API sales.
  • Polling & reconciliationRecover from missed webhooks with deliveries replay and order reads.
  • Idempotency & retriesIdempotency-Key contract, orderReference, and safe retry behavior.
  • Partner runbookSandbox vs production, strict mode, and operational checks.