Mindbodyonline Mindbody Public API

Name: Mindbody Public API
Brand: Mindbody Public API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentHealthcareAppointment SchedulingapiKey, bearer142 EndpointsREST

For Agents

Install Jentic One Beta

Connect the Mindbody Public API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Mindbody Public API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Mindbody Public API.

Look up bookable items and active staff schedules to drive client booking flows

Read and create class enrollments and appointment bookings on behalf of clients

Pull client profiles, visit history, and account balances for support agents

GET STARTED

Start building with Mindbody Public API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Mindbody Public API for, with concrete tasks.

★ Client Self-Service Booking

An agent surfaces bookable appointment and class slots from Mindbody to a client-facing chatbot or website, then creates the booking on the client's behalf. The studio sees the new booking appear directly in Mindbody alongside walk-in and front-desk bookings.

Call GET /appointment/bookableitems for a date range, present matching slots to the client, then book the chosen slot using the appropriate appointment-creation endpoint.

Studio Operations Dashboard

Operators centralise multi-site reporting by pulling appointments, classes, sales, and payroll out of Mindbody for each SiteId. The dashboard refreshes nightly so studio managers see the same numbers as the Mindbody back office without logging in.

For each SiteId, fetch yesterday's sales and payroll endpoints and roll the totals into a multi-site dashboard.

Staff Scheduling and Coverage

An agent reads a studio's available dates, schedule items, and staff appointments to spot coverage gaps and suggest shift swaps. The studio manager validates and applies changes inside Mindbody, with the agent acting as the analysis layer.

Pull GET /appointment/availabledates and GET /appointment/staffappointments for next week, then flag time blocks where bookable demand exceeds staffed hours.

Personalised Client Outreach

Marketing agents pair client visit history from Mindbody with a messaging tool to send win-back or upsell messages targeted at the right cohort. Mindbody supplies the source-of-truth on who came in, when, and what they bought.

Pull clients with no visits in the last 60 days, build a SMS list, and trigger a win-back campaign in the connected messaging tool.

Agent-Driven Studio Operations via Jentic

Through Jentic, an agent calls Mindbody operations by intent rather than wrestling with three-header auth (API-Key + SiteId + staff bearer). The credentials sit in your Jentic One instance and the right combination is injected at execution time, including running /usertoken/issue when a staff token is required.

Use Jentic search 'list bookable appointments at a mindbody site', load the schema for GET /appointment/bookableitems, and execute with the SiteId and date range.

Key Endpoints

142 endpoints — jentic publishes the only available openapi specification for mindbody public api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/appointment/bookableitems

Get appointment availabilities for booking

GET

/appointment/scheduleitems

Get schedule items including appointments and unavailabilities

GET

/appointment/staffappointments

Get appointments by staff member

GET

/appointment/availabledates

Get dates staff are scheduled to work

GET

/appointment/appointmentoptions

Get appointment configuration options

GET

/appointment/activesessiontimes

Get active business hours for studios

GET

/appointment/bookableitems

Get appointment availabilities for booking

GET

/appointment/scheduleitems

Get schedule items including appointments and unavailabilities

GET

/appointment/staffappointments

Get appointments by staff member

GET

/appointment/availabledates

Get dates staff are scheduled to work

GET

/appointment/appointmentoptions

Get appointment configuration options

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Your Mindbody API-Key, SiteId, and staff bearer token are stored once, encrypted, by your own Jentic One instance and injected as the correct headers at execution time. They never enter the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'list bookable appointments at a Mindbody site' or 'find a client', and Jentic returns the matching Mindbody operation with its input schema so the agent calls GET /appointment/bookableitems without parsing the developer portal.

Time to first call

FAQs

Specific to using Mindbody Public API through Jentic.

Why is there no official OpenAPI spec for Mindbody Public API?

Mindbody publishes documentation at developers.mindbodyonline.com but not an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Mindbody Public API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

What authentication does the Mindbody Public API use?

Each request requires the developer API-Key header and a SiteId header that identifies the studio. Operations that act on behalf of a staff user also require a bearer token issued by /usertoken/issue. Through Jentic, all three credentials live in the vault and are injected per request without entering the agent's context.

Can I list bookable appointment slots through the API?

Yes. GET /appointment/bookableitems returns availabilities for booking appointments at the configured SiteId, which is the supported way to power a custom booking surface that mirrors the Mindbody calendar.

What are the rate limits for the Mindbody Public API?

Mindbody enforces per-developer-key and per-site rate limits documented at developers.mindbodyonline.com. Expect a 429 response when limits are hit; back off and retry, and contact Mindbody for higher tiers if a single site needs heavier integration traffic.

How do I issue a staff user token through Jentic?

Run pip install jentic, search for 'issue a mindbody staff user token', load the schema for POST /usertoken/issue, and execute with the staff username and password. Jentic stores the resulting token alongside the API-Key and SiteId for downstream calls.

Does this API let me manage multiple studios?

Yes. The SiteId header selects the target studio per request, so a single API-Key can drive operations across every Mindbody site that has authorised the developer account.

Can I limit what my agent is allowed to do with the Mindbody Public API?

Yes. Because Jentic One is self-hosted, you decide which Mindbody operations the agent may call, so you can allow read-only calls like GET /appointment/bookableitems and GET /appointment/scheduleitems while excluding sales or payroll writes. Many Mindbody operations pass the SiteId and target ids in headers or the request body rather than the URL path, so scoping happens at the operation level under your own rules. A privileged action, such as issuing a staff token via /usertoken/issue or writing a sale, is only reachable if you add it to the allowed set. Your API-Key, SiteId, and staff bearer token stay in your Jentic One instance and are injected at execution time, never in the agent's context.