Mindbody

Before configuring anything in Bubble, you need two pieces of information from Mindbody: your API key and your studio's SiteId. Get your API key Go to developers.mindbodyonline.com. If you do not have a developer account, click Sign Up and create one using your studio's Mindbody credentials. Once logged in, navigate to the API Keys section and create a new API key for your application. Give it a descriptive name (e.g., Bubble Custom Portal). Copy the API key value — you will paste it into the Bubble API Connector in the next step. Get your SiteId Your SiteId is a numeric identifier that Mindbody assigns to your studio location. Find it in one of these places: - The Mindbody developer portal under your account information - Your Mindbody software settings under Account → Site Details - In the URL when you are logged into your Mindbody manager account (often visible as a numeric segment in the URL path) For development and testing, use SiteId -99. This is Mindbody's official sandbox environment — all API calls with SiteId -99 use Mindbody's test data and create no real bookings for real clients. It is essential to use -99 throughout development so you do not accidentally create fake bookings for real studio clients. Verify API access Before setting up Bubble, verify that your API key is active by testing a simple call in an API testing tool (like Postman or any browser-based REST client). Send a GET to https://api.mindbodyonline.com/public/v6/class/classes with headers API-Key: your-key and SiteId: -99. If you receive a 200 response with class data, your credentials are valid. If you receive a 401, double-check the API key. If you receive a 403, your Mindbody subscription may not include API access — contact Mindbody support.

1{
2  "Test call (verify credentials)": {
3    "method": "GET",
4    "url": "https://api.mindbodyonline.com/public/v6/class/classes",
5    "headers": {
6      "API-Key": "<your_api_key>",
7      "SiteId": "-99"
8    }
9  }
10}

Set up the API Connector plugin in Bubble with the Mindbody credentials as Private shared headers. Install the API Connector In the Bubble editor, click the Plugins tab in the left panel. Click Add plugins and search for API Connector. Select API Connector by Bubble and click Install. Click on the installed plugin to open the configuration panel. Create the Mindbody API group In the API Connector panel, click Add another API. Configure: - API Name: Mindbody - Authentication: None or self-handled - Shared headers (applied to every call in this group): - Header name: API-Key, value: your Mindbody API key — check the Private checkbox - Header name: SiteId, value: -99 (for development; you will change this to your production SiteId before launch) — the Private checkbox is optional for SiteId if you consider it non-sensitive, but marking it Private adds a layer of protection against exposing your specific studio location to client-side inspection - Header name: Content-Type, value: application/json (for POST calls) Why Private matters: Bubble runs API Connector calls from Bubble's servers, not from the user's browser. When a header is marked Private, Bubble also prevents the value from appearing in any client-side JavaScript it generates for your app. This means a user who opens browser developer tools and inspects network traffic will never see your API-Key. Without the Private checkbox, the key could theoretically be visible in Bubble's client-side code. Do not put client AccessTokens (from the usertoken endpoint) in the shared headers — those are per-user and per-session tokens that go in individual API call headers, not the shared group headers.

1{
2  "Mindbody API group config": {
3    "API Name": "Mindbody",
4    "Authentication": "None or self-handled",
5    "Shared headers": [
6      { "key": "API-Key",       "value": "<your_api_key>",  "private": true },
7      { "key": "SiteId",        "value": "-99",             "private": true },
8      { "key": "Content-Type",  "value": "application/json", "private": false }
9    ]
10  }
11}

Add the class schedule GET call and initialize it so Bubble can detect the response structure and expose it as a data source for Repeating Groups. Add the Get Classes call Inside the Mindbody API group, click Add another call. Configure: - Call name: Get Classes - Method: GET - URL: https://api.mindbodyonline.com/public/v6/class/classes - Use as: Data (this binds the call result to page elements directly) - Parameters (query string): - StartDateTime: a start date-time in ISO 8601 format, e.g., 2026-07-10T00:00:00 (you will make this dynamic later) - EndDateTime: an end date-time, e.g., 2026-07-10T23:59:59 - HideCancelledClasses: true (omit cancelled classes from results) Initialize the call Click Initialize call. Bubble sends a real GET request to the Mindbody sandbox with SiteId -99. If the sandbox returns classes for the specified date range, Bubble detects the response structure: a Classes array where each item has fields like ClassDescription.Name, StartDateTime, EndDateTime, MaxCapacity, TotalBooked, Staff.Name, and Location.Name. After successful initialization, all detected fields become available in Bubble's expression editor. If the initialize call returns an empty Classes array (no classes scheduled in the sandbox for that date), Bubble may not detect the field structure. Try different dates or use a date range that is known to have sandbox data. The Mindbody sandbox (SiteId -99) has pre-populated class data on specific dates. Make the dates dynamic After initialization, go back to the Get Classes call parameters and replace the hardcoded date strings with dynamic expressions. Set StartDateTime and EndDateTime to accept values from page inputs. Bubble will prompt you to provide these values when you bind the call to a Repeating Group.

1{
2  "Get Classes call": {
3    "method": "GET",
4    "url": "https://api.mindbodyonline.com/public/v6/class/classes",
5    "params": {
6      "StartDateTime": "<start_datetime>",
7      "EndDateTime": "<end_datetime>",
8      "HideCancelledClasses": "true"
9    },
10    "headers": {
11      "API-Key": "<private>",
12      "SiteId": "<private>"
13    }
14  }
15}

Booking a class on behalf of a specific client requires a second level of authentication. Mindbody issues a short-lived AccessToken (usertoken) per client. You must call the /v6/usertoken/issue endpoint with the client's Mindbody email and password to get this token, then use it in the booking call. Add the Issue UserToken call In the Mindbody API group, click Add another call. Configure: - Call name: Issue UserToken - Method: POST - URL: https://api.mindbodyonline.com/public/v6/usertoken/issue - Body type: JSON - Body: { "Username": "<client_email>", "Password": "<client_password>" } - Use as: Action (this is called from a button workflow, not displayed directly in a data element) Click Initialize call. Use a test client account's email and password in the sandbox. Mindbody returns an AccessToken and a UserId. After successful initialization, these fields are available as outputs of the Action in Bubble workflows. Store the AccessToken in App State Do not store the client's Mindbody password in Bubble's database. Only store the AccessToken, and only for the duration of the user's session. Add a custom state to the page (type: text, name: mindbody_access_token). In the workflow that calls Issue UserToken, add a Set state action immediately after: set mindbody_access_token to Result of Step 1's AccessToken. When the user closes the browser or navigates away, the page state clears automatically. The AccessToken is never persisted to the database — only used during the active session. Never pass Mindbody client credentials through a URL parameter or page state that persists across sessions. Always use the usertoken flow to get a fresh, short-lived token for each session.

1{
2  "Issue UserToken call": {
3    "method": "POST",
4    "url": "https://api.mindbodyonline.com/public/v6/usertoken/issue",
5    "headers": {
6      "API-Key": "<private>",
7      "SiteId": "<private>",
8      "Content-Type": "application/json"
9    },
10    "body": {
11      "Username": "<client_email>",
12      "Password": "<client_password>"
13    }
14  }
15}

With the class schedule call and usertoken call configured, add the booking action and connect everything into a complete user-facing flow. Add the Book Class (addclienttoclass) call In the Mindbody API group, click Add another call. Configure: - Call name: Book Class - Method: POST - URL: https://api.mindbodyonline.com/public/v6/class/addclienttoclass - Body type: JSON - Body: { "ClassId": <class_id>, "ClientId": "<client_mindbody_id>" } - Additional header (on this specific call, not shared): Authorization: Bearer <access_token> - Use as: Action The Bearer token in the Authorization header is the AccessToken obtained from the usertoken call. The ClientId is the Mindbody client ID returned alongside the AccessToken when you called /v6/usertoken/issue. Store it in a second page custom state (mindbody_client_id). Build the booking page UI Create a page called class-booking. Add: - A Date Input at the top (label: Select a date) - A Repeating Group with data source: Get data from an external API → Mindbody — Get Classes, with StartDateTime wired to the Date Input's value at start of day and EndDateTime wired to the Date Input's value at end of day - Inside the Repeating Group: text elements for class name (Classes's ClassDescription Name), instructor (Classes's Staff Name), start time (Classes's StartDateTime formatted as time), and spots remaining (Classes's MaxCapacity minus Classes's TotalBooked) - A Book This Class button on each row - A popup (Group Focus or Popup element) that appears when Book is clicked, containing email and password inputs and a Confirm Booking button Wire the booking workflow on Confirm Booking: 1. Call Mindbody — Issue UserToken with Email = email input, Password = password input 2. Set state mindbody_access_token to Result of Step 1's AccessToken 3. Set state mindbody_client_id to Result of Step 1's UserId 4. Call Mindbody — Book Class with ClassId = Parent Group's ClassId (the class the user was viewing when they clicked Book) and ClientId = page state mindbody_client_id, with Bearer header = page state mindbody_access_token 5. Show a success popup: Class booked! Check your email for confirmation. RapidDev's team has built custom booking portals on Bubble for fitness studios integrating with Mindbody's API — if you need help wiring the complete booking flow or handling edge cases like waitlists and cancellations, book a free scoping call at rapidevelopers.com/contact.

1{
2  "Book Class call": {
3    "method": "POST",
4    "url": "https://api.mindbodyonline.com/public/v6/class/addclienttoclass",
5    "headers": {
6      "API-Key": "<private>",
7      "SiteId": "<private>",
8      "Content-Type": "application/json",
9      "Authorization": "Bearer <access_token>"
10    },
11    "body": {
12      "ClassId": "<class_id>",
13      "ClientId": "<client_mindbody_id>"
14    }
15  }
16}

Before going live, add Privacy rules for any data stored in Bubble's database, switch from the sandbox to your production SiteId, and test the complete flow. Add Privacy rules If you store any Mindbody data in Bubble's database (for example, a BookingRecord Data Type logging each booking), go to Data → Privacy → BookingRecord and add a rule: When Current User is BookingRecord's user — all fields visible. Client booking history is personal data and should only be readable by the client it belongs to. Switch to production In the API Connector, go to the Mindbody API group and update the SiteId shared header value from -99 to your real studio SiteId. This single change switches all calls from the sandbox to your live Mindbody account. Double-check before clicking away — the production SiteId connects to real client accounts and live booking data. Test the production connection In Bubble's preview mode, load the class booking page with the production SiteId configured. Verify: - Classes appear for the current date range (your studio must have classes scheduled) - The class details (instructor name, capacity, time) are correct - Test the booking flow using a real Mindbody client account at your studio — confirm the booking appears in Mindbody's manager console - Check the Logs tab → Workflow logs to verify no 401 or 429 errors Monitor WU consumption Each API Connector call to Mindbody consumes WU on your Bubble plan. For a class booking page that loads on page open (triggering the Get Classes call), estimate WU per call from the Logs tab and project monthly WU usage based on expected visitor volume. If your studio attracts high traffic, consider caching class schedule data in a Bubble Data Type that refreshes hourly rather than querying Mindbody on every page load.