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. /Checkout holds

Checkout holds

POST and DELETE /orders/hold for soft inventory reservation at checkout.

TopicsSell an order

Short-lived capacity coordination between POST /orders/preview and POST /orders. Use holds to reduce preview→payment races without enabling hot-drop mode.

Checkout hold states#

Diagram
holdDELETETTLPOST /ordersHeldReleasedExpiredConsumed
holdDELETETTLPOST /ordersHeldReleasedExpiredConsumed

Holds do not pull keys. Authority remains the order commit path.

When to use#

  1. POST /api/seller/v1/orders/preview — gate on canFulfill (do not charge if false).
  2. Optional: POST /api/seller/v1/orders/hold — reserve a slot for the checkout window (default 30 minutes, matching a hosted PSP page). Send countryCode and integrationOrderContext (including buyer IP) so territory and consumer-geo gates fail before payment — same CONSUMER_* / TERRITORY_* codes as preview.
  3. Charge the buyer at your PSP.
  4. POST /api/seller/v1/orders with the same SKU, quantity, orderReference, and optional checkoutHoldId.

Capability discovery#

curl -s -X POST "https://api.avrix.io/api/seller/v1/orders/hold" \
  -H "Authorization: Bearer $AVRIX_API_KEY" \
  -H "Idempotency-Key: hold-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
  }
}'

curl -s -X POST "https://api.avrix.io/api/seller/v1/orders/hold"
-H "Authorization: Bearer avrix_sk_sbx_your_key_here"
-H "Content-Type: application/json"
-H "Idempotency-Key: hold-store-order-10432"
-d '{ "skuCode": "SANDBOX-ALWAYS-001", "quantity": 1, "orderReference": "store-order-10432" }'

Successful response (`data.type`: `checkout_hold`): | Field | Meaning | | --- | --- | | `holdId` | Pass as `checkoutHoldId` on `POST /orders` | | `expiresAt` / `expiresInSeconds` | TTL remaining | | `allocationId` | Bound allocation | | `maxFulfillableQuantity` | Ceiling observed at hold time | Common errors: **409** sold out, **404** SKU/allocation, **412** hold disabled. ### `DELETE /api/seller/v1/orders/hold` **Requires** `Idempotency-Key`. Release on cart abandon: ```bash curl -s -X DELETE "https://api.avrix.io/api/seller/v1/orders/hold" \ -H "Authorization: Bearer avrix_sk_sbx_your_key_here" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: release-hold-store-order-10432" \ -d '{ "holdId": "<uuid>" }'

Bind on create order#

Optional checkoutHoldId on POST /orders must match seller, SKU, quantity, and orderReference. The hold is consumed on successful pull.

TTL#

Default hold lifetime is 30 minutes (platform-clamped window, one minute to one hour), sized to a hosted PSP checkout. Expired holds release automatically; prefer explicit DELETE on abandon so other shoppers see capacity sooner.

A lapsed hold never blocks a paid order. If POST /orders references a checkoutHoldId that has expired, been released, or been consumed, the commit proceeds as a plain order (inventory from the pool, price from priceCommitmentToken / expectedUnitPriceCents) and the response carries checkoutHold: { holdId, status: "expired", committedWithoutHold: true }. Only a hold that exists but does not match the body is rejected (422 HOLD_MISMATCH, recommended action fallback_to_post_orders_without_hold).

Revocation#

If the publisher revokes or pauses the allocation grant while holds are open, the platform cancels those holds immediately (allocation.updated arrives with reason: "revoked" or "paused"). A POST /orders carrying a cancelled checkoutHoldId fails hold validation — treat it like an expired hold: re-preview, and if the SKU is no longer sellable, refund the buyer at your PSP.

vs hot-drop#

Checkout holdHot-drop reserve
Requires hot-drop modeNoYes
Commit pathPOST /ordersPOST /orders/commit
Typical TTLMinutesAbout 60 seconds
When to useOrdinary checkout racesDeclared launches above ~500 RPS

Related#

  • Creating orders
  • Hot drop
  • Order preview

What links here

Published guides that link to this page.

  • 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.
  • Hot-drop reserve & commitHigh-throughput reserve and commit for vendor-declared launches.
  • TroubleshootingSymptom-first trees for auth, empty catalog, inventory, idempotency, and webhooks.
PreviousOrder contextNextHot-drop reserve & commit

Need help with this page?

Contact support

AI tools

  • Ask ChatGPT
  • Ask Claude

On this page

  • Checkout hold states
  • When to use
  • Capability discovery
  • `DELETE /api/seller/v1/orders/hold`
  • Bind on create order
  • TTL
  • Revocation
  • vs hot-drop
  • Related

Related pages

  • Order previewRead-only price and fulfillment estimate before checkout.
  • Creating ordersPOST /orders fields, safe creation pattern, and unknown-outcome recovery.
  • Hot-drop reserve & commitHigh-throughput reserve and commit for vendor-declared launches.
  • Store integration profilesProfile A/B/C checkout patterns — preview, hold, and hot-drop.
  • Error referenceHTTP statuses, canonical error codes, and recovery actions.