Rollout phases
The Management API is published as a whole and delivered in phases. Every operation's description carries the phase it belongs to, so the reference tells you what is live without a second document to cross-check.
| Phase | Contents | Availability |
|---|---|---|
| Phase 0 | Orders read (fetchOrders) and order webhooks, order-level promotion attribution | Live — credentials and test stores on request |
| Phase 1 | Directory reads (locations, brands, stores), store status with discrepancy classification, pause/unpause, hours read and write, item catalogue and availability, menu assignments | Next — first build priority |
| Phase 2 | Reporting: async generation, download, programmatic coverage matrix | After Phase 1 |
| Phase 3 | Promotions: reads and platform-scoped writes, within each platform's ceilings | After Phase 2 |
| Phase 4 | Menus: full document reads, bounded edits, publish orchestration | After Phase 3 |
What a published-but-unimplemented operation means
The contract is real and final: field names, types, enum members and semantics are committed, and they will not be renamed or narrowed once published. What has not shipped is the implementation behind it, and until it does the operation answers 501.
You can build against such an operation today. What you must not do is treat the 501 as a transient fault and retry it — see Getting Started → Errors and retries.
Why publish ahead of implementation
Because the shape is the part you have to design your system around, and the shape is settled well before the query behind it is. Publishing it early lets an integration be written in parallel with the build rather than after it; holding it back would buy nothing but a shorter document.
Coverage is documented, not discovered by failing
Where a capability is limited by a delivery platform, the limit is documented and — from Phase 2 — discoverable programmatically. You should never find a gap by hitting it.