Introduction
The Swoop API connects a Point-of-Sale (POS) system to Swoop's on-course food & beverage ordering. A Swoop member orders from their phone — at the turn, on the range, or out on the 4th hole — and the order lands in your POS as a normal to-go ticket. As your kitchen works the ticket, status flows back to the member live: received → in progress → ready → on its way.
The integration is mediated by the swoop-api-adapter, a standalone service that sits between Swoop and your POS:
Swoop app swoop-api-adapter Your POS
───────── ───────────────── ──────────
member places orderPlaced ┌───────────────┐ CreateOrder ┌──────────┐
an order ───────────────────► │ enrich + │ ──────────────► │ to-go │
│ canonicalize │ │ ticket │
member sees │ │ ◄────────────── │ │
live status ◄───────────────── │ status-back │ webhook └──────────┘
orderStatus └───────────────┘ (status)
Changed
What you integrate against
There are three seams, and you only touch the ones your POS needs:
- The data contract. Swoop hands your integration a provider-agnostic order — never a Swoop- or vendor-specific shape. You translate it into your POS's create-order call.
- The status webhook. When your POS advances a ticket, it posts a webhook to
POST /webhook/{integration}/{locationId}. You send the order-status change; Swoop maps it onto the member's order. - Configuration. Each club is mapped to your integration by a tenant config row — adding or moving a club is config, never a change to Swoop's core.
Provider-agnostic by design
Every Swoop-side concept (orders, status, menu) is expressed in one vendor-neutral canonical contract, so any POS plugs in identically — there is no "preferred" POS. If you can create a to-go order and report a status change, you can integrate.
Where to go next
- New here? Start with Getting Started.
- Securing the connection? See Authentication.
- The shapes on the wire? See the Order Lifecycle.