Changelog

Every change to the Swoop API — the partner-facing contract in the API Reference — is recorded here, newest first.

How the API is versioned. The API is versioned by addition: new fields and new paths are additive and backward-compatible, and a field is never removed or repurposed within a version. Anything marked Added is safe to ignore until you need it. A breaking change would ship under a new version prefix — none has been needed yet.

1.1.0 — July 2026

Added

• Named request examples on the order-injection contract (beverage pickup, multi-item with modifiers, delivery to an on-course marker), the order-status webhook, and the mission-event webhook — pick them from the example dropdown in the reference.
• A ready-to-run Postman collection generated from the OpenAPI document: one request per operation, folders per suite, example bodies filled in.

Docs

• Per-suite tables of contents with deep links to every operation, a persistent request/response code panel on wide screens, and color-coded response statuses in the API Reference.
• Examples audited against live data: realistic order ids, numeric item/modifier/marker ids, US club timezones and coordinates, and collection codes derived from the order id.
• The Location model is location-keyed only — everything Swoop-side (menu, markers, webhooks) is addressed by locationId; every order for a location routes to one fulfilment station.

1.0.0 — June 2026

Initial public contract:

• Orders — the order-injection contract (idempotent on externalRef), the order-status webhook (at-least-once, monotonic), and cancel/void with staff-routing fallback.
• Menu — menu read (items + modifier groups) and item availability / 86'ing as both a push event and a poll.
• Delivery — mission create / abort / get, the mission-event webhook, and optional live position telemetry.
• Locations — the club → site → on-course marker model, including delivery drop-off mapping.
• Integration Configuration — the onboarding-time registration and location-mapping contracts.