How to Integrate Bolt.new with Mindbody

Before writing any integration code, you must apply for Mindbody API access through their developer partner program. Mindbody's API is not self-serve — it requires formal approval. Go to developers.mindbodyonline.com and click 'Get API Access'. You will be asked to describe your integration use case, the business(es) you are building for (must be existing Mindbody customers), your expected API usage volume, and technical details about your implementation. The application process takes approximately 1-2 weeks. Mindbody reviews applications to ensure the integration serves a legitimate business need and that the developer understands the platform. During this time, you can access Mindbody's API documentation and sandbox environment (limited) using a test API key, but full production access requires approval. Mindybody's API has several subscription tiers that affect which endpoints are available. The Consumer API (public-facing, limited) allows reading class schedules and staff information. The Partner API (requires approval) adds client management, bookings, sales, and reporting. Ensure your Mindbody subscription tier supports the API features you need — contact Mindbody sales if you are unsure. Key credentials you will receive upon approval: API Key (a static key sent in the Api-Key header), Site ID (a negative integer identifying the business location, sent as SiteId in requests), and OAuth 2.0 client credentials (client_id and client_secret) for obtaining access tokens. Store all of these in your Bolt .env file. Never expose them in client-side code. While waiting for approval: start building your Bolt app with the Supabase prototype approach described in use case 3. Design your components and user flows now — the data shape returned by Mindbody's API is well-documented, so you can build to spec even before having access.

1// Mindbody API endpoints reference
2// Base URL: https://api.mindbodyonline.com/public/v6
3//
4// Authentication:
5// POST /usertoken/issue — OAuth client credentials token
6// Headers: Api-Key, SiteId, Content-Type: application/json
7// Body: { "Username": "Siteowner", "Password": "YOUR_API_KEY" }
8//
9// Key endpoints:
10// GET /class/classes — class schedule
11// GET /class/classschedules — recurring class schedule templates
12// GET /staff/staff — staff list
13// GET /site/sessiontypes — available session/service types
14// GET /appointment/staffappointmentavailabilities — appointment slots
15// POST /class/addclienttoclass — enroll client in class
16// POST /appointment/bookappointment — book appointment
17//
18// Note: All requests require:
19// - Api-Key header: your developer API key
20// - SiteId header: the business site ID (negative integer)
21// - Authorization: Bearer {access_token} (for write operations)

Mindbody's API uses a unique OAuth implementation that is slightly different from standard OAuth 2.0 client credentials. The token endpoint at /public/v6/usertoken/issue accepts a JSON body with Username and Password. For a staff-level or site owner token (needed for admin operations), Username is 'Siteowner' and Password is your API key. For a specific staff user token, use their Mindbody credentials. The token response includes an AccessToken (a JWT string) and a TokenType ('Bearer'). Access tokens expire after 60 minutes. Cache the token and its expiry time in a module-level variable to avoid fetching a new token before every API call — this is important for performance and to stay within Mindbody's rate limits. All Mindbody API requests require three things: the Api-Key header (your static developer key, present in every request), the SiteId header (the business site ID, present in every request), and the Authorization: Bearer {token} header (the OAuth access token, required for authenticated operations). Some read-only endpoints (like class schedules) work without the Authorization header if the studio's settings allow public access. During development in Bolt's WebContainer, the token fetch and subsequent API calls all work correctly — Mindbody's API is accessible over HTTPS from the WebContainer's outbound networking. Test your authentication setup by making a simple call to /public/v6/site/sites to verify your credentials are correct before building out the full feature set.

1// lib/mindbody.ts
2const BASE = 'https://api.mindbodyonline.com/public/v6';
3const API_KEY = process.env.MINDBODY_API_KEY!;
4const SITE_ID = process.env.MINDBODY_SITE_ID!;
5
6interface TokenCache {
7  token: string;
8  expiresAt: number;
9}
10
11let tokenCache: TokenCache | null = null;
12
13export async function getMindbodyToken(): Promise<string> {
14  if (tokenCache && Date.now() < tokenCache.expiresAt) {
15    return tokenCache.token;
16  }
17
18  const res = await fetch(`${BASE}/usertoken/issue`, {
19    method: 'POST',
20    headers: {
21      'Api-Key': API_KEY,
22      'SiteId': SITE_ID,
23      'Content-Type': 'application/json',
24    },
25    body: JSON.stringify({ Username: 'Siteowner', Password: API_KEY }),
26  });
27
28  if (!res.ok) {
29    const err = await res.text();
30    throw new Error(`Mindbody auth failed: ${err}`);
31  }
32
33  const data = await res.json();
34  tokenCache = {
35    token: data.AccessToken,
36    expiresAt: Date.now() + 55 * 60 * 1000, // 55 min (token valid 60)
37  };
38  return tokenCache.token;
39}
40
41async function mindbodyFetch<T>(
42  endpoint: string,
43  options: RequestInit = {}
44): Promise<T> {
45  const token = await getMindbodyToken();
46  const res = await fetch(`${BASE}${endpoint}`, {
47    ...options,
48    headers: {
49      'Api-Key': API_KEY,
50      'SiteId': SITE_ID,
51      'Authorization': `Bearer ${token}`,
52      'Content-Type': 'application/json',
53      ...options.headers,
54    },
55  });
56  if (!res.ok) {
57    const err = await res.text();
58    throw new Error(`Mindbody API ${endpoint} failed (${res.status}): ${err}`);
59  }
60  return res.json();
61}
62
63export const mindbody = {
64  get: <T>(endpoint: string) => mindbodyFetch<T>(endpoint),
65  post: <T>(endpoint: string, body: unknown) =>
66    mindbodyFetch<T>(endpoint, { method: 'POST', body: JSON.stringify(body) }),
67};

With authentication working, create the Next.js API routes that power the booking interface. The class schedule route fetches upcoming classes from Mindbody's /class/classes endpoint, filters by date range, and returns lean objects suitable for the frontend calendar. The booking route creates a class enrollment (adds the client to a class) via the /class/addclienttoclass endpoint. Mindbody's class schedule endpoint returns rich data including the class name, description, instructor (Staff object), location (Location object), start and end times, the session type (yoga, pilates, spin, etc.), available enrollment capacity, and the total maximum capacity. Map these to the shape your frontend expects. For client enrollment, you need a client_id — Mindbody's identifier for the person booking. New clients can be created via /client/clients POST. Existing clients are looked up by email via /client/clients?searchText=email@example.com. The class enrollment endpoint requires a ClassId and a ClientId. If the client pays through Mindbody (using a pass or credits), include payment details in the enrollment request. For testing in the Bolt preview: create a test client via the Mindbody portal (not the API), then use that client's ID in your test booking API calls. This lets you verify the booking flow works end-to-end in the WebContainer before deploying. Remember that actual bookings made during testing affect your Mindbody schedule — use future-dated test classes at low or zero capacity to avoid conflicts.

1// app/api/classes/route.ts
2import { NextResponse } from 'next/server';
3import { mindbody } from '@/lib/mindbody';
4
5interface MindbodyClass {
6  Id: number;
7  ClassDescription: { Name: string; Description: string };
8  Staff: { FirstName: string; LastName: string };
9  StartDateTime: string;
10  EndDateTime: string;
11  Location: { Name: string };
12  TotalBooked: number;
13  MaxCapacity: number;
14  IsCanceled: boolean;
15}
16
17interface ClassesResponse {
18  Classes: MindbodyClass[];
19}
20
21export async function GET(request: Request) {
22  try {
23    const { searchParams } = new URL(request.url);
24    const startDate = searchParams.get('startDate') ?? new Date().toISOString();
25    const endDate = searchParams.get('endDate') ??
26      new Date(Date.now() + 7 * 24 * 60 * 60 * 1000).toISOString();
27
28    const data = await mindbody.get<ClassesResponse>(
29      `/class/classes?StartDateTime=${encodeURIComponent(startDate)}&EndDateTime=${encodeURIComponent(endDate)}&HideCanceled=true`
30    );
31
32    const classes = (data.Classes ?? []).map((c) => ({
33      id: c.Id,
34      name: c.ClassDescription.Name,
35      description: c.ClassDescription.Description,
36      instructor: `${c.Staff.FirstName} ${c.Staff.LastName}`,
37      startDateTime: c.StartDateTime,
38      endDateTime: c.EndDateTime,
39      location: c.Location.Name,
40      spotsAvailable: Math.max(0, c.MaxCapacity - c.TotalBooked),
41      totalSpots: c.MaxCapacity,
42    }));
43
44    return NextResponse.json(classes);
45  } catch (error: unknown) {
46    const e = error as { message: string };
47    return NextResponse.json({ error: e.message }, { status: 500 });
48  }
49}

With the API routes returning Mindbody data, prompt Bolt to generate the complete booking interface. The UI should present the class schedule in a format that matches the studio's brand — either a weekly calendar grid, a day-by-day list, or a filtered card view. Each class card shows the key information clients need to decide whether to book: class name, instructor, time, duration, location, and remaining spots. The booking flow should be simple and fast: one click to open the booking modal, a minimal form (new clients provide name, email, phone; returning clients enter email to look up their profile), and an immediate confirmation. For studios with membership and pricing plans, display whether the class requires credits and how many the client has remaining — though this requires additional API calls to fetch the client's contract and visit count. Client-facing booking flows should handle two states: anonymous (client is not logged in, provide contact info to book as a visitor or create a new Mindbody account) and returning (client provides email to look up existing Mindbody account). For the anonymous path, the /client/clients POST endpoint creates a new Mindbody client account as part of the booking process. Availability refresh is important: class spots fill up in real time, especially for popular classes. Use SWR with automatic revalidation (revalidateOnFocus: true, refreshInterval: 60000) so spots available stays current as the user browses. Show a clear 'Class full — join waitlist' state when spotsAvailable reaches 0.

Deploy your Bolt app to Netlify to get a public HTTPS URL, required for receiving Mindbody webhook events (booking confirmations, cancellations, payments). Mindbody's webhook system (called 'Partner Webhooks' in their documentation) sends POST requests to your endpoint when specific business events occur — a new booking, a cancellation, a check-in, or a payment. To deploy: connect your Bolt project to Netlify via Settings → Applications → Netlify → Publish. After deploying, add environment variables in Netlify Dashboard: MINDBODY_API_KEY, MINDBODY_SITE_ID, MINDBODY_CLIENT_ID, MINDBODY_CLIENT_SECRET, and MINDBODY_WEBHOOK_SECRET (used to verify incoming webhook payloads). Trigger a redeploy. Webhook registration is done through the Mindbody Developer Portal, not the API. Log into developers.mindbodyonline.com, navigate to your app's webhook settings, and add your Netlify URL (https://your-app.netlify.app/api/webhooks/mindbody). Select the event types you want to receive. During Bolt WebContainer development, incoming webhooks from Mindbody cannot reach the browser-based runtime — there is no public URL for Mindbody to POST to. This is a fundamental constraint of the WebContainer architecture. For webhook testing, deploy to Netlify first. You can simulate webhook payloads during development by calling your POST /api/webhooks/mindbody route directly with test JSON matching Mindbody's webhook event format. The Mindbody webhook payload includes the event type, site_id, event details (booking ID, client info, class info), and a signature for verification. Verify the signature before processing to prevent unauthorized requests to your handler.

1# netlify.toml
2[build]
3  command = "npm run build"
4  publish = ".next"
5
6[build.environment]
7  NODE_VERSION = "20"
8
9[[plugins]]
10  package = "@netlify/plugin-nextjs"