Skip to main content

​
Channel ID

Every request must include an X-Channel-Id header. This identifies which merchant’s storefront you’re accessing — it determines the outlets, menus, branding, and payment configuration the diner sees You receive the channel ID when a merchant is onboarded to Atlas. It is a fixed identifier, not a secret

​
Sessions

Start by calling GET /channel with your channel ID. This creates a session and returns it in the X-Session-Id response header 
curl -sD - https://api.atlas.kitchen/storefronts/v1/channel \
  -H "X-Channel-Id: your-channel-id"

# Response header — save this
X-Session-Id: b7ac755d301dc5d23c790ccd7bb6dadf
Include both headers on all subsequent requests:
HeaderWhat it isWhere it comes from
X-Channel-IdMerchant’s storefront identifierProvided during onboarding
X-Session-IdDiner’s session (tracks cart)Returned by GET /channel
GET /channel is the only endpoint that creates a session. All other endpoints require a valid X-Session-Id header — calling them without one returns 401 Unauthorized
Read-only endpoints (menus, stocks, timeslots, availabilities, announcements, banners, popups) work with just X-Channel-Id — no session needed

​
Session lifecycle

A session holds a reference to the diner’s active cart. There’s always exactly one active cart per session at any time.
  • Creation: the first GET /channel call creates a session and returns X-Session-Id
  • Reuse: pass the same X-Session-Id on subsequent GET /channel calls to keep the same session (and cart). Send no session, and a new one is minted
  • After checkout: when POST /cart/order succeeds, the session’s active cart is marked is_checked_out: true and a fresh empty cart is created for the same session. The session ID stays valid — reuse it for the diner’s next order
Persist X-Session-Id in local storage. As long as it’s valid, returning diners keep their cart across page reloads.