Seller levels
Seller Levels grade how much of a seller's side is connected versus run by hand. Levels are cumulative, and a seller can stop climbing at any rung and still transact.
| Level | Capability | Typical build |
|---|---|---|
| 0 | Batch order intake, async accept/reject against a known rate card | Files + console. About a week. Or an intake endpoint you already host. |
| 1 | Rate-card distribution (your card, served or pushed) | A feed or a weekly file. |
| 2 | Live availability; partial acceptance | An avails endpoint or push stream. |
| 3 | Negotiation: counters and alternatives on rejection | Respond flow, or console counters. |
| 4 | Last-minute fast lane: sync decisions, holds with TTL, clearance pricing | Real-time systems. |
rate_management.rates names how your card moves, frozen_quarterly or live, and capabilities.realtime_availability names how your avails do: the two dimensions are declared separately, and most sellers start frozen and climb one dimension at a time; the long tail can stay at Level 0 forever and still transact. Your Level appears as conformance_level on your capability profile, computed from the capabilities you declare at /v1/me/capabilities rather than stated: the level is the highest unbroken rung your declarations support, per the decision table on that page. The orchestrator degrades gracefully around whatever you have not declared and never calls what your profile does not advertise.
avails_policy and pricing_policy are set per product, independent of your Level, and are served through the proposal path.