Frontdesk Booking System

What this is

the one-paragraph version

Today, a business that uses Mindbody can only take online bookings through Mindbody's own pages. We want to let them take bookings through our surfaces instead — a booking widget on their own website, our AI front-desk agent, and so on — while the appointment still lands in their Mindbody calendar.

To do that, our backend speaks to Mindbody on the business's behalf. Everything Mindbody-specific is hidden inside one place in our code (the "adapter"), so the same booking widget can later work for Square, Vagaro, Acuity and others without being rewritten.

The big picture

five hops from website to Mindbody

Plain-English glossary

terms used below, defined once

Onboarding options

how a studio gets connected to us

"Onboarding" = the one-time setup where a studio links their Mindbody to us. There are three realistic ways to do it. The first is what we do today and want to move away from.

How we authenticate with Mindbody

the three things that let our server make calls

Once a studio is connected, every call our backend makes to Mindbody is authorized by a combination of three things. None of them is the studio's password — we never see that.

Why not OAuth?

a deliberate decision

OAuth is the "Log in with…" flow. In Mindbody it is primarily a consumer-level mechanism — an individual customer granting an app access to their own activity (visits and purchases) through the Consumer Activity API. When you create an OAuth client, its "Client Use for" setting is literally "Consumer API Access."

It is technically possible to have an OAuth client specially provisioned with the Mindbody.Api.Public.v6 scope to reach business data — but that requires extra setup from Mindbody and is not the standard way partners integrate.

The customer journey

what a person booking on the studio's website experiences

This mirrors the prototype. Each step lists, in plain terms, what the backend does behind it.

Pricing model

the price a specific customer actually pays — resolved before they book

The widget does not show one catalogue price. It shows the price this customer pays: their tier (member / intro / standard), any staff surcharge, and whether a promo code is valid. Nothing is charged online — the widget creates the booking only, and the resolved summary goes into the booking note for the front desk to apply at checkout.

Three tiers, resolved up front

Every customer lands in one tier, decided at Screen 1 · Identify from a live lookup — deterministic, not a guess. The labels are the same everywhere; the dollar amounts come from each location's mirror.

What the customer sees

validated on Deka Wexford · Classic Full Set — Standard $180 · Intro $119.99 · Member $135

Where each number comes from

Zoca is the menu · the mirror is the pricing engine · Mindbody is the booking engine

Latency budget

per-call targets at the widget (including our hop) — Instant = our DB, Live = one Mindbody round-trip, Heavy = scrape or multi-leg

What the backend does (at a glance)

most of it already exists

API reference & contracts

what we shipped, and the shape of every call

All endpoints at a glance

The widget system is platform-agnostic by design. The customer-facing surface never names a booking platform: it speaks our own vocabulary and reads from our own database. A specific platform — Mindbody first — is an implementation detail that lives behind the booking layer.

Onboarding & connect

api-server · authenticated

Requestjson{ "entityId": "uuid", "siteId": "28902" }

Response: activation requiredjson{ "result": "activation_required",
  "activationCode": "fGjY7C/tBOsd2+K6wfgqfw==",
  "activationLink": "https://clients.mindbodyonline.com/classic/ws?auto=studioId=28902&code=..." }

Response: connectedjson{ "result": "Mindbody connected successfully" }

RequesthttpGET /auth/mindbody/activation-status?entityId=uuid&siteId=28902

Response: pendingjson{ "result": "activation_pending" }

Response: connectedjson{ "result": "Mindbody connected successfully" }

Public widget — catalogue (our DB)

tasks-server · @Public · our canonical types

Responsejson{ "entityId": "uuid",
  "services": [ { "id": "uuid", "name": "Classic Full Set",
      "duration": { "value": 60 },
      "price": { "value": 65, "metadata": { "currency": "USD" } },
      "categories": [ { "id": "uuid", "name": "Full Sets", "orderIndex": 1 } ],
      "hasAddons": true,
      "addons": [
        { "id": "uuid", "name": "Hydrating Eye Mask",
          "priceCents": 1500, "durationMinutes": 10 }
      ],
      "attributes": { "platformServiceId": "298" } } ],
  "servicesTotal": 47, "servicesPage": 1, "servicesLimit": 20,
  "categories": [ { "id": "uuid", "name": "Full Sets", "orderIndex": 1 } ],
  "preferences": { "onlineBookingEnabled": true, "cancellation": { "windowHours": 24 },
    "cardRequirement": "first_time" } }

RequesthttpGET /frontdesk/widget/:entityId/services?page=1&limit=20&search=massage

Responsejson{ "services": [
    { "id": "uuid", "name": "Classic Full Set",
      "hasAddons": true,
      "addons": [
        { "id": "uuid", "name": "Hydrating Eye Mask",
          "priceCents": 1500, "durationMinutes": 10 }
      ] }
  ],
  "totalCount": 47, "page": 1, "limit": 20, "hasMore": true }

RequesthttpGET /frontdesk/widget/:entityId/staff?serviceId=uuid

Responsejson{ "staff": [
    { "id": "uuid", "firstName": "Surry", "lastName": "Singh",
      "referenceId": "100000000", "isBookableOnline": true,
      "isServiceProvider": true, "title": null, "specializations": [],
      "surcharge": { "amountCents": 2000, "label": "Master Lash Artist" } }
] }

Public widget — booking (platform)

tasks-server · @Public · resolved through the adapter

RequesthttpGET /frontdesk/widget/:entityId/availability?serviceId=uuid&from=2026-06-19&days=14

Responsejson{ "serviceId": "uuid", "from": "2026-06-19", "window": 14,
  "dates": [ "2026-06-19", "2026-06-20" ],
  "days": [ { "date": "2026-06-19",
              "slots": [ { "time": "10:00 AM", "endTime": "11:00 AM",
                           "staffId": "uuid", "staffName": "Surry Singh",
                           "providers": [ { "staffId": "uuid", "name": "Surry Singh" } ] } ] } ],
  "nextAvailable": { "date": "2026-06-19", "slots": [] } }

RequesthttpGET /frontdesk/widget/:entityId/slots?serviceId=uuid&date=2026-06-19

Responsejson{ "date": "2026-06-19", "serviceId": "uuid",
  "slots": [ { "time": "10:00 AM", "endTime": "11:00 AM",
               "staffId": "uuid", "staffName": "Surry Singh",
               "providers": [ { "staffId": "uuid", "name": "Surry Singh" } ] } ],
  "totalSlots": 8, "hasOpenings": true }

Requestjson{ "date": "2026-06-19", "slot": "10:00 AM",
  "serviceId": "uuid", "staffId": "uuid?", "sessionId": "uuid" }

Responsejson{ "holdId": "uuid", "staffId": "uuid", "expiresAt": "...Z",
  "startTime": "...Z", "endTime": "...Z", "timezone": "America/New_York" }

Requestjson{ "phone": "+15551234567", "name": "Jane Doe", "email": "jane@x.com" }

Responsejson{ "success": true, "platformClientId": "100045", "message": "Client ready" }

Requestjson{ "promoCode": "WELCOME10" }

Response: validjson{ "valid": true,
  "code": "WELCOME10",
  "discountType": "percent",
  "discountAmount": 10,
  "message": "Promo code will be applied at checkout." }

Response: invalidjson{ "valid": false,
  "code": "WELCOME10",
  "discountType": null,
  "discountAmount": null,
  "message": "Promo code not found." }

Requestjson{ "phone": "+15551234567", "name": "Jane Doe", "email": "jane@x.com",
  "date": "2026-06-19", "slot": "10:00 AM",
  "serviceId": "uuid", "staffId": "uuid?", "holdId": "uuid",
  "promoCode": "WELCOME10", "note": "optional" }

Responsejson{ "success": true,
  "appointmentId": "100098",
  "bookingStatus": "BOOKED",
  "message": "Appointment booked" }

Retry responsejson{ "success": true, "alreadyBooked": true, "message": "Already booked" }

Request: leadjson{ "phone": "+15551234567",
  "email": "jane@x.com",
  "name": "Jane Doe" }

Request: funneljson{ "phone": "+15551234567",
  "stage": "service_selected",
  "serviceId": "uuid" }

Responsejson{ "success": true,
  "stage": "service_selected",
  "followUpActive": true }

Public widget — card on file

tasks-server · @Public · PCI-clean card vault

Response: on filejson{ "requirement": "always",
  "required": true,
  "supported": true,
  "clientFound": true,
  "hasCardOnFile": true }

Response: not on filejson{ "requirement": "always",
  "required": true,
  "supported": true,
  "clientFound": true,
  "hasCardOnFile": false }

Response: email-only (no unfiltered search)json{ "requirement": "first_time",
  "required": false,
  "supported": true,
  "clientFound": false,
  "hasCardOnFile": false }

Responsejson{ "supported": true,
  "token": "abc123",
  "submitUrl": "https://pci.zoca-tech.com/card",
  "bookingRef": "uuid",
  "completeUrl": "https://widget.zoca-tech.com/card-saved" }

The Mindbody layer

what "the platform" means behind the curtain

Everything above is platform-neutral. This is the Mindbody-specific work that sits behind the booking layer — the only part that knows Mindbody exists.

Catalog sync

freeze pricing & add-ons into mirror tables — once at sync, then instant at serve-time

The catalog sync is the keystone of the pricing architecture. It fetches Mindbody's full session-type and sale-service catalogue, runs all fragile name/program matching once, and stores the results in mirror tables that serve the widget with pure Postgres lookups.

Trigger sync (relay server)bashcurl -s -X POST \
  http://localhost:3002/relay/api/v1/integrated-platforms/$ENTITY/sync-catalog

Responsejson{
  "serviceMeta": 27,
  "pricingTiers": 81,
  "addons": 20,
  "serviceAddonLinks": 20,
  "staffLinked": 48
}

Choice · Where slots come from

how we know what times are open

Card-on-file flow

requirement gate → check on file → collect if needed — PCI-clean

The widget inserts a card-on-file gate between price confirm and booking. The flow has three stages:

Charging cards · no-show fees & deposits required later phase

what's actually needed to take money

Good news: charging a card does not need Mindbody Payments / Connect. You charge through the Public API (CheckoutShoppingCart) against whatever active merchant account the studio already has (TSYS, Bluefin, Elavon, Paysafe, Adyen, Ezidebit, or Mindbody Payments — any one). Connect is only for tokenizing a card so we never see the raw number; it is not required to take the money.

The real difference between a no-show fee and a deposit is when the card gets captured:

What v1 must leave open (so this isn't a rewrite later)

• Card-capture seam — even though v1 takes no money, design the booking flow so a card-capture step (Connect token or PCI enclave) can be dropped in without reworking the widget or the booking API.
• Merchant-account awareness — during onboarding, detect & record whether each studio can actually charge (active processor / Mindbody Payments), so the widget knows when deposits/no-show are even possible.
• Adapter seams — reserve captureCard?, chargeNoShow?, chargeDeposit? + capability flags on the platform adapter (optional methods, like the ones it has today).
• Data model — a home for the no-show / deposit policy (per service or location), the stored card-on-file reference, and a charge / refund audit trail.
• Confirm early — the CheckoutShoppingCart "pay with card on file" payload + SCA behaviour, and the deposit refund / reconciliation rules, before Phase 2 starts.

Implementation reference

The build, screen by screen — file map, per-screen behavior, cross-cutting machinery, and testing evidence. Branch feat/mindbody-widget-pricing.

the mirror-cache architecture, and the one safety rule

Pricing and booking run from our own Postgres mirror — zero live Mindbody calls for the browse and base price path. The key design insight: all fragile name/program matching happens once at sync time, and booking becomes pure reverse-map lookups. Promo codes are the exception: they are validated against Mindbody /site/promocodes, then stamped into the booking note for checkout instead of deducted in-widget.

Legend used per screen: Zoca DB = served from our database (instant) · Mindbody (live) = a real-time API call · Mirror = our synced Postgres mirror tables · stored = written to our DB.

File map

Screen 1 · Identify

phone + name → resolve the pricing tier

The new first screen. We look the customer up and classify them — read-only, never creating a client.

RequesthttpPOST /tasks/api/v1/frontdesk/widget/:entityId/identify

Responsejson{ "supported": true,
  "platform": "mindbody",
  "tier": "new",
  "isExistingClient": false,
  "includedCredits": 0 }

Controllerts// apps/tasks-server/.../frontdesk-widget.controller.ts
@Post(':entityId/identify')
@Public()
async identify(@Param('entityId', ParseUUIDPipe) entityId: string,
               @Body() body: WidgetIdentifyDto) {
  if (!body?.phone && !body?.email) throw new BadRequestException('phone or email is required');
  const result = await this.integratedPlatforms.resolveClientTier(entityId, { phone: body.phone, email: body.email });
  // platformClientId + memberships stay server-side — every later endpoint re-resolves by phone.
  return { supported: result.supported, platform: result.platform, tier: result.tier,
            isExistingClient: result.isExistingClient, includedCredits: result.includedCredits ?? 0 };
}

Tier rule (mindbody.service.ts)ts// active membership              → 'member'
// no membership, has appointment
//   history (past or upcoming,
//   checked live)                → 'returning'
// no history — a client record
//   alone (inquiry, gift card)
//   does NOT forfeit intro       → 'new'
// IsProspect is only the fallback
//   prior when the live history
//   lookup itself fails

Screen 2 · Service

pick a service — with category order and embedded add-ons

Request: confighttpGET /tasks/api/v1/frontdesk/widget/:entityId/config

Request: serviceshttpGET /tasks/api/v1/frontdesk/widget/:entityId/services?page=1&limit=20

Responsejson{ "services": [
  { "id": "uuid", "name": "Classic Full Set",
    "price": { "value": 127.99 },
    "hasAddons": true,
    "addons": [
      { "id": "uuid", "name": "Hydrating Eye Mask",
        "priceCents": 1500, "durationMinutes": 10 }
    ],
    "categories": [ { "id": "uuid", "name": "Full Sets", "orderIndex": 1 } ] }
],
  "hasMore": true }

Screen 3 · Add-ons

optional extras — immediately after service, skipped when empty

Service payloadjson{ "id": "uuid",
  "name": "Classic Full Set",
  "hasAddons": true,
  "addons": [
    { "id": "uuid", "name": "Hydrating Eye Mask",
      "priceCents": 1500, "durationMinutes": 10 }
  ] }

Screen branchtsif (service.hasAddons) {
  showAddons(service.addons);
} else {
  goToStaff();
}

Screen 4 · Staff

pick a provider — Master Lash Artist is a staff surcharge

RequesthttpGET /tasks/api/v1/frontdesk/widget/:entityId/staff?serviceId=uuid

Responsejson{ "staff": [
  { "id": "uuid", "firstName": "Emily",
    "surcharge": { "amountCents": 2000, "label": "Master Lash Artist" } },
  { "id": "uuid", "firstName": "Alex",
    "surcharge": null }
] }

Typetsexport interface StaffSurcharge {
  amountCents: number;
  label?: string;
}

Screen 5 · Slot

pick a time — and hold it

Request: availabilityhttpGET /tasks/api/v1/frontdesk/widget/:entityId/availability?serviceId=uuid&from=2026-06-19&days=14

Request: holdhttpPOST /tasks/api/v1/frontdesk/widget/:entityId/hold

Responsejson{ "holdId": "uuid",
  "expiresAt": "2026-06-19T14:10:00.000Z",
  "timezone": "America/New_York" }

Screen 6 · Price & promo

tier price from mirror + staff surcharge; promo verified, not deducted

RequesthttpPOST /tasks/api/v1/frontdesk/widget/:entityId/price

Response — mirror path (no promo)jsonc{
  "supported": true,
  "tier": "member",
  "tierLabel": "Member",
  "originalCents": 18000,      // standard tier (mirror) → strikethrough
  "finalCents": 13500,         // member tier from service_pricing_tiers
  "reason": "Membership pricing",
  "surcharge": {
    "amountCents": 2000,       // staff surcharge from /staff rule
    "label": "Master Lash Artist"
  },
  "lines": [
    { "name": "Classic Full Set", "amountCents": 13500 },
    { "name": "Master Lash Artist", "amountCents": 2000 }
  ]
}

Request: verify-promohttpPOST /tasks/api/v1/frontdesk/widget/:entityId/verify-promo

Response: verify-promojson{ "valid": true,
  "code": "WELCOME10",
  "discountType": "percent",
  "discountAmount": 10,
  "message": "Promo code will be applied at checkout." }

Rendered lines (Deka Wexford · Emily · member)Classic Full Set   $̶1̶8̶0̶.̶0̶0̶   $135.00   ← member tier from mirror
Master Lash Artist            +$20.00   ← MLA surcharge
  Membership pricing                    ← reason

Screen 7 · Card on file

requirement gate → collect card if needed

Request: card-statushttpPOST /tasks/api/v1/frontdesk/widget/:entityId/card-status

Response: card required, on filejson{ "requirement": "always",
  "required": true,
  "supported": true,
  "clientFound": true,
  "hasCardOnFile": true }

Response: card required, not on filejson{ "requirement": "always",
  "required": true,
  "supported": true,
  "clientFound": true,
  "hasCardOnFile": false }

Response: card never requiredjson{ "requirement": "never",
  "required": false,
  "supported": true,
  "clientFound": true,
  "hasCardOnFile": false }

Request: collect-cardhttpPOST /tasks/api/v1/frontdesk/widget/:entityId/collect-card

Responsejson{ "supported": true,
  "token": "abc123",
  "submitUrl": "https://pci.zoca-tech.com/card",
  "bookingRef": "uuid",
  "completeUrl": "https://widget.zoca-tech.com/card-saved" }

Screen 8 · Booking

confirm — booking only, with the pricing note

Requestjson{ "phone": "+15551234567",
  "serviceId": "uuid",
  "staffId": "uuid",
  "holdId": "uuid",
  "promoCode": "WELCOME10",
  "note": "Tier: Member; Price: $135; Surcharge: $20; Promo: WELCOME10 (apply at checkout)" }

Booking notets// createMindbodyBooking gained an optional note → appointment Notes
const appointmentData: MindbodyAddAppointmentRequest = {
  ClientId, LocationId, SessionTypeId, StaffId, StartDateTime, SendEmail: true,
  ...(note ? { Notes: note } : {}),   // pricing summary + verified promo for the front desk
};

Cross-cutting · Lead funnel

lead → service selected → slot selected → booked

Request: leadjson{ "phone": "+15551234567",
  "email": "jane@x.com",
  "name": "Jane Doe" }

Request: funneljson{ "phone": "+15551234567",
  "stage": "slot_selected",
  "serviceId": "uuid",
  "slot": "10:00 AM" }

Responsejson{ "success": true,
  "stage": "slot_selected",
  "followUpActive": true }

Cross-cutting · Dev write-guard

the "no Mindbody writes in dev" guarantee, behind every mutation

Write guardts// libs/mindbody/src/lib/mindbody.service.ts
private assertMindbodyWriteAllowed(operation: string): void {
  if (this.configService.isDevelopment()) {
    this.logger.warn(`<MINDBODY> BLOCKED write "${operation}" — disabled in development.`);
    throw new HttpException(`Mindbody writes are disabled in development (blocked: ${operation}).`, HttpStatus.FORBIDDEN);
  }
}

Cross-cutting · The layering

Every new capability is added at each layer so the widget speaks only our types and the platform stays swappable:

Testing it

three test surfaces: Deka Wexford (mirror + identify), Deka Green Tree (card-on-file), and Mindbody sandbox -99 (full write path)

Pricing & identify — Deka WexfordbashENTITY=2b21fbb0-7716-4af8-846b-0306a4922dae
BASE=http://localhost:8001/tasks/api/v1/frontdesk/widget/$ENTITY

# 1. Identify tier (no platformClientId in the response — public route)
curl -s -X POST "$BASE/identify" -d '{"phone":"+14125551234"}' -H 'Content-Type: application/json'
# → {"supported":true,"platform":"mindbody","tier":"member","isExistingClient":true,"includedCredits":1}

# 2. Browse services (embedded add-ons + hasAddons)
curl -s "$BASE/services?page=1&limit=20"
# → service.hasAddons: true; service.addons: [...]

# 3. Browse staff for service (staff surcharge) — never the full roster
curl -s "$BASE/staff?serviceId=<uuid>"
# → Emily → surcharge.amountCents: 2000; Alex → surcharge: null

# 4. Price (mirror path — instant)
curl -s -X POST "$BASE/price" \
  -d '{"serviceId":"<uuid>","tier":"member","staffId":"<emily-uuid>"}' \
  -H 'Content-Type: application/json'
# → finalCents: 13500 (member), surcharge.amountCents: 2000 (MLA)

# 5. Verify promo (validation only — not deducted in widget)
curl -s -X POST "$BASE/verify-promo" \
  -d '{"promoCode":"WELCOME10"}' -H 'Content-Type: application/json'
# → {"valid":true,"code":"WELCOME10","discountType":"percent","discountAmount":10,...}

# 6. Write guard fires on a Deka site
curl -s -X POST "$BASE/client" -d '{"phone":"+14125551234"}' -H 'Content-Type: application/json'
# → "Mindbody writes are disabled in development (blocked: addClient)."

Card-on-file — Deka Green Tree (site 5748465)bashENTITY=<green-tree-entity-id>
BASE=http://localhost:8001/tasks/api/v1/frontdesk/widget/$ENTITY

# 1. Card status (requirement gate + on-file check — no card brand/last-four, public route)
curl -s -X POST "$BASE/card-status" \
  -d '{"phone":"+14125551234"}' -H 'Content-Type: application/json'
# → {"requirement":"always","required":true,"supported":true,"clientFound":true,"hasCardOnFile":true}

# 2. Collect card (mints PCI token → inline form POSTs PAN directly to lambda)
curl -s -X POST "$BASE/collect-card" \
  -d '{"phone":"+14125551234"}' -H 'Content-Type: application/json'
# → {"token":"...","submitUrl":"https://pci.zoca-tech.com/card","completeUrl":"..."}
# The widget posts PAN directly to submitUrl; no iframe, no card number through our API.
# The lambda vaults the card in Mindbody and redirects to completeUrl.

Full write path — Mindbody API sandbox (site -99)bash# Site -99 is the ONLY site exempted from the dev write-guard.
# Use it to test client creation and real appointment booking end-to-end in dev.
ENTITY=<entity-id-for-site--99>
BASE=http://localhost:8001/tasks/api/v1/frontdesk/widget/$ENTITY

# 1. Get availability
curl -s "$BASE/availability?serviceId=<uuid>&from=$(date +%Y-%m-%d)&days=14"

# 2. Hold a slot
curl -s -X POST "$BASE/hold" \
  -d '{"date":"<date>","slot":"10:00 AM","serviceId":"<uuid>","sessionId":"<any-uuid>"}' \
  -H 'Content-Type: application/json'
# → {"holdId":"uuid","expiresAt":"...","timezone":"..."}

# 3. Book (write allowed on -99 in dev)
curl -s -X POST "$BASE/book" \
  -d '{"phone":"+15551234567","name":"Test User","date":"<date>","slot":"10:00 AM","serviceId":"<uuid>","holdId":"<holdId>","promoCode":"WELCOME10"}' \
  -H 'Content-Type: application/json'
# → {"success":true,"appointmentId":"...","bookingStatus":"BOOKED"}
# Follow-ups for the matching lead/funnel cancel automatically on booking.

What's left

Built on feat/mindbody-widget-pricing · served via the sonar Cloudflare tunnel · internal only.

What we reuse vs. what we add

keeping the build small

Reuse (already in the codebase)

Listing services, staff, availability; finding/creating a customer; creating, cancelling and rescheduling appointments — all already work in the Mindbody adapter.

Add (small, targeted)

Embedded service add-ons, a slot-hold, promo verification, lead/funnel tracking, the public booking API, the widget itself, and the availability accuracy fixes below.

Availability accuracy fixes

1. Paging — today we only read the first page of times, so busy days get cut off. Read them all.
2. Sorting — times currently sort as text, so "10:00 AM" can appear before "9:00 AM". Sort by actual time.
3. End time — trust Mindbody's end time instead of recomputing it.
4. "Any provider" — show one time once, not once per available staff member.

Security · public-widget hardening

the widget routes are public — no OTP/auth yet, deliberately deferred — so this is what stands in for it today

Every /frontdesk/widget/* route is @Public: no login, no session token, tied only to :entityId in the path. OTP-based phone verification (§ Open questions-adjacent, tracked as a follow-up) is the eventual fix; until it ships, four things do the work of keeping the surface honest — implemented in widget-rate-limit.guard.ts, frontdesk-widget.controller.ts, frontdesk-widget.service.ts, and main.ts.

Security to fix

remaining, now that the public-route hardening above is in

• addressed The card collection path now uses one-time PCI tokens minted per session by /collect-card. The inline widget form POSTs the PAN directly to the PCI lambda using this token — no iframe, no fixed API key, and no card number through our API.
• addressed Public endpoints now carry per-IP rate limiting (10/min sensitive, 120/min general) and a CORS_ALLOWED_ORIGINS allow-list — see Security hardening above.
• addressed /identify and /card-status no longer leak platformClientId or card metadata.
• Move the hard-coded Mindbody credentials in our code into environment settings.
• Give card-collection tokens an expiry (today they're one-use, but the expiry policy should be explicit).
• Move the rate-limit store to Redis once tasks-server runs multi-instance (in-memory per-process today).
• OTP-based phone verification + short-lived session tokens — the real fix for phone-as-identity spoofing; everything above is a stopgap until this ships.

Open questions for Mindbody

things to confirm before the later phases

The plan

order of work

1. First (nothing blocking): availability fixes → embedded service add-ons → staff surcharge → promo verification → lead funnel → slot hold → public booking API → the widget → wire the prototype to live data.
2. Alongside: the security fixes (rotate the leaked key especially).
3. Then: cards & deposits, once we confirm Mindbody's tokenization.
4. Later: webhooks for live availability, and onboarding polish.

Mindbody documentation

source references — what each link covers

Internal design doc — plain-language draft, no secrets included. Based on the Mindbody Public API, our codebase (Mindbody adapter, frontdesk services), and the dekalash prototype. Chatbot lib and the old widget lib are out of scope.