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. /Sell an order
  3. /Hot-drop reserve & commit

Hot-drop reserve & commit

High-throughput reserve and commit for vendor-declared launches.

TopicsSell an order

Two-step fulfilment for vendor-declared launch windows where peak demand on a single allocation exceeds what a single POST /orders round-trip should absorb (roughly >500 RPS sustained).

For ordinary catalog browsing and steady-state checkout, keep using POST /api/seller/v1/orders. Reserve + commit is two HTTP round-trips and adds latency.

When to use#

Use reserve/commit only when all of these are true:

  • The vendor has enabled hot-drop mode on the allocation.
  • You are integrating a declared launch (major drop, timed release, high-contention SKU).
  • You expect contention above ~500 reserve RPS on that SKU.
  • You can release or let TTL expire if the buyer abandons checkout.

Below that threshold, direct POST /orders is usually faster end-to-end.

Flow#

Diagram
commitreserveStoreBuyercommitreserveStoreBuyerAdd to cartsku + qtyreservationIdHold for payPSP paidreservationIdKeysDeliver
commitreserveStoreBuyercommitreserveStoreBuyerAdd to cartsku + qtyreservationIdHold for payPSP paidreservationIdKeysDeliver

If the buyer abandons, the reservation expires (about 60 seconds). Explicit cancel/release is friendlier to other shoppers when your flow supports it.

POST /api/seller/v1/orders/reserve#

Requires Idempotency-Key. API-model allocations also run territory and consumer-geo gates (same CONSUMER_* / TERRITORY_* codes as preview). Send countryCode and, under enforcement, integrationOrderContext.consumerIp before you charge. See Territory enforcement.

curl -s -X POST "https://api.avrix.io/api/seller/v1/orders/reserve" \
  -H "Authorization: Bearer $AVRIX_API_KEY" \
  -H "Idempotency-Key: reserve-store-10432" \
  -H "Content-Type: application/json" \
  -d '{
  "skuCode": "SANDBOX-ALWAYS-001",
  "quantity": 1,
  "countryCode": "NL",
  "orderReference": "store-order-10432",
  "integrationOrderContext": {
    "schemaVersion": 1,
    "salesCountryCode": "NL",
    "currencyCode": "EUR",
    "salesPriceGrossMinor": 7999,
    "priceIncludesTax": true,
    "salesTaxRatePercent": 21,
    "salesChannel": "web",
    "salesTaxAmountMinor": 1388
  }
}'

Successful response (200):

JSON
{
  "data": {
    "type": "reservation",
    "reservationId": "f9f7e2c8-...",
    "allocationId": "...",
    "quantity": 1,
    "expiresAt": "2026-08-05T18:21:00.000Z",
    "expiresInSeconds": 60,
    "remainingSlots": 14987,
    "orderReference": "store-order-10432"
  }
}
StatusCodeWhen
404NOT_FOUNDNo active allocation for your seller
403FORBIDDENAllocation paused or revoked
412HOT_DROP_NOT_ENABLEDAllocation not in hot-drop mode — use POST /orders
409SOLD_OUTNo remaining slots
422QUANTITY_INVALIDQuantity must be a positive integer
503STORE_UNAVAILABLECoordination store down — backoff; direct /orders may be acceptable

POST /api/seller/v1/orders/commit#

Requires Idempotency-Key.

Bash
curl -s -X POST "https://api.avrix.io/api/seller/v1/orders/commit" \
  -H "Authorization: Bearer avrix_sk_sbx_your_key_here" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: commit-store-order-10432" \
  -d '{
    "reservationId": "f9f7e2c8-...",
    "integrationOrderContext": {
      "schemaVersion": 1,
      "salesCountryCode": "US",
      "currencyCode": "USD",
      "salesPriceGrossMinor": 1999,
      "salesPriceNetMinor": 1999,
      "priceIncludesTax": true,
      "salesTaxAmountMinor": 0,
      "salesTaxRatePercent": 0,
      "salesChannel": "web",
      "paymentMethodFamily": "card",
      "paymentProcessorReference": "pay_3QxK2mB9",
      "checkoutSessionId": "cs_store_10432",
      "consumerIp": "198.51.100.42"
    }
  }'

Successful response matches POST /orders (type: "fulfilled" with keys, or preorder shape).

StatusCodeWhen
410RESERVATION_GONEExpired, unknown, or already consumed — re-reserve
409ALLOCATION_NOT_AVAILABLEAllocation paused / hot-drop flipped off mid-flight

Note: Each reservation can be committed once. A second commit after success typically returns RESERVATION_GONE. Persist entitlements from the first successful response.

Idempotency#

Both reserve and commit require Idempotency-Key. Retry network faults with the same key and body. See Idempotency.

Anti-patterns#

  • Calling /orders/reserve on non-hot-drop allocations (412 every time).
  • Calling /orders/commit without a prior reserve — use POST /orders instead.
  • Polling reserve to “warm” counters — burns write budget.
  • Treating remaining slots as a storefront stock badge — use GET /availability for display.

Related#

  • Checkout holds — softer coordination for ordinary checkout
  • Creating orders
  • Order lifecycle

What links here

Published guides that link to this page.

  • Checkout holdsPOST and DELETE /orders/hold for soft inventory reservation at checkout.
  • Creating ordersPOST /orders fields, safe creation pattern, and unknown-outcome recovery.
  • Error referenceHTTP statuses, canonical error codes, and recovery actions.
  • GlossaryCanonical terms for sellers, SKUs, allocations, orders, and fulfillment.
  • Rate limitsPer-tier request ceilings, headers, and Retry-After guidance.
PreviousCheckout holdsNextFulfillment & keys

Need help with this page?

Contact support

AI tools

  • Ask ChatGPT
  • Ask Claude

On this page

  • When to use
  • Flow
  • `POST /api/seller/v1/orders/reserve`
  • `POST /api/seller/v1/orders/commit`
  • Idempotency
  • Anti-patterns
  • Related

Related pages

  • Checkout holdsPOST and DELETE /orders/hold for soft inventory reservation at checkout.
  • Order previewRead-only price and fulfillment estimate before checkout.
  • Creating ordersPOST /orders fields, safe creation pattern, and unknown-outcome recovery.
  • Store integration profilesProfile A/B/C checkout patterns — preview, hold, and hot-drop.
  • Error referenceHTTP statuses, canonical error codes, and recovery actions.