Quickstart

Go from zero to your first API call in a few minutes. You will issue a key, make a read against the Storefront API, and make a write against the Management API.

The API is split into two surfaces, each with its own key kind:

Both are path-versioned at /v1; within v1 we only ever make additive changes, so an integration you ship today keeps working.

1. Issue your keys

Keys are created and revoked in your studio dashboard:

Studio dashboard → Settings → Developer (/studio/api-keys)

There you can:

• Create a publishable key (flow_pk_…). This is browser-safe by design — it is read-only, scoped to your studio, and meant to ship in your website's code.
• Create a secret key (flow_sk_…) and choose its scopes (see below). The full secret is shown once, at creation time — copy it then; we only store a hash, so it can never be shown again. Store it somewhere safe (a secrets manager or your server's environment), never in client-side code or git.
• Revoke any key instantly, and review the API activity log for recent calls made with your keys.

Each key resolves to exactly one studio. A request can only ever read or write that studio's own data.

Scopes (secret keys)

A secret key carries a least-privilege set of scopes. Grant only what the integration needs:

A call to an operation whose scope the key does not hold is rejected with 403 Forbidden and a Problem body. See Authentication & scopes and Errors for the generated scope table and response format. Publishable keys are read-only.

2. Base URLs

Each surface has its own endpoint. The exact host for your studio is shown on the Developer page; the examples below use placeholders plus the local-dev ports the specifications declare.

# Production (copy the exact host from your dashboard)
STOREFRONT_API="https://storefront.example.com/v1"
MANAGEMENT_API="https://management.example.com/v1"

# Local development (from the published specs)
# STOREFRONT_API="http://127.0.0.1:48004/v1"
# MANAGEMENT_API="http://127.0.0.1:48005/v1"

Authentication is the same everywhere: a bearer token carrying your key.

Authorization: Bearer flow_pk_…   # storefront (publishable)
Authorization: Bearer flow_sk_…   # management (secret)

3. Your first read (Storefront)

List the studio's upcoming classes. This is the storefrontListClasses operation — GET /v1/classes, read-only, authenticated with the publishable key:

curl "$STOREFRONT_API/classes" \
  -H "Authorization: Bearer flow_pk_your_publishable_key"

Response:

{
  "classes": [
    {
      "classTitle": "Morning Flow",
      "discipline": "vinyasa",
      "level": "all-levels",
      "startsAt": "2026-07-01T07:00:00.000Z",
      "durationMinutes": 60,
      "instructorName": "Alex Rivera"
    }
  ]
}

Other storefront reads work the same way: GET /v1/instructors (storefrontListInstructors), GET /v1/plans (storefrontListPlans), GET /v1/site (storefrontGetSite), GET /v1/policies (storefrontGetPolicies), and GET /v1/config (storefrontGetConfig). See the Storefront reference for every field.

4. Your first write (Management)

Create a class with its first occurrence. This is the managementCreateClass operation — POST /v1/classes. It requires the classes:write scope and a secret key, and you should send an Idempotency-Key header so a retry never creates a duplicate (see Idempotency):

curl -X POST "$MANAGEMENT_API/classes" \
  -H "Authorization: Bearer flow_sk_your_secret_key" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 6f9619ff-8b86-d011-b42d-00c04fc964ff" \
  -d '{
    "title": "Sunset Slow Flow",
    "mode": "broadcast",
    "instructorId": "8c1e0b2a-7f3d-4a9c-9b1e-2d3f4a5b6c7d",
    "startsAt": "2026-07-10T18:30:00.000Z",
    "durationMinutes": 75,
    "discipline": "yin",
    "level": "all-levels",
    "capacity": 40,
    "visibility": "public"
  }'

mode is one of broadcast, two_way, community, or coaching. To make the class repeat, add a recurrence object ({ "intervalDays": 7, "count": 8 }).

Other management operations: managementUpdateClass (PATCH /v1/classes/{classId}), managementCancelClass (DELETE /v1/classes/{classId}), managementListMembers (GET /v1/members), managementInviteMember (POST /v1/members/invites), managementListSchedule (GET /v1/schedule), managementRescheduleOccurrence (POST /v1/schedule/{occurrenceId}), managementUpdateContent / managementDeleteContent (PUT / DELETE /v1/content/{contentId}). See the Management reference.

Pagination

Management list endpoints are cursor-paginated. A page is { "data": [ … ], "next_cursor": "…" }. Pass the value back as ?cursor= to get the next page (and ?limit= to size each page, max 100):

curl "$MANAGEMENT_API/classes?limit=50&cursor=eyJpZCI6…" \
  -H "Authorization: Bearer flow_sk_your_secret_key"

When next_cursor is absent or null, you have reached the last page. See Pagination for the generated list of cursor-paginated operations.

Audit trail

Every call made with one of your keys is recorded, and the recent activity is visible on the Developer page (which key, which operation, when, and the outcome). This gives you an at-a-glance trail for debugging an integration and a record of what each key has been doing — useful before you rotate or revoke a key.

Next

• Storefront API reference — every public read.
• Management API reference — every read and write.
• Embeddable SDK — add member sign-in and checkout to your own website with one script tag.