November 2022 - Endpoint Updates

New Endpoints

September 2022 - Endpoint Updates

New Endpoints

Modified Endpoints

Bug Fixes

August 2022 - Endpoint Updates

New Endpoints - Mindbody Consumer APIs

Modified Endpoints

Bug Fixes

July 2022 - Endpoint Updates

POST CheckoutShoppingCart.
We have changed the validation message in the checkout shopping cart endpoint when purchasing the product with instore value as false.

June 2022 - Endpoint Updates

GET Clients.
We added a limitation in the Get Client request for ClientIds, now maximum of 20 client IDs can be passed in the parameter of the endpoint.

Bug Fixes

May 2022 - Endpoint Updates

Bug Fixes

April 2022 - Endpoint Updates

New Endpoints

March 2022 - Endpoint Updates

New Endpoints

Bug Fixes

February 2022 - Endpoint Updates

New Endpoints

Bug Fixes

January 2022 - Endpoint Updates

V6.0 endpoint access

GET Packages

Nov 2021 - Endpoints Update

OnlineDescription

Oct 2021 - Endpoints Update

Recipient Client ID

Update Product Price

Sept 2021 API Updates

Custom Staff ID

Aug 2021 - Endpoint updates

POST CheckoutShoppingCart

July 2021 - New Endpoint

GET ActiveClientsMemberships

June 2021 – New and Updated Endpoints

GET StaffSessionTypes

POST AddStaffAvailability

POST AssignStaffSessionType

POST UpdateStaffPermissions

GET Clients and POST UpdateClient

GET ClientRewards

POST UpdateClientRewards

GET ClientFormulaNotes

POST AddClientFormulaNote

DELETE ClientFormulaNote

GET ClientContracts

POST PurchaseGiftCard

April 2021 - Enhancements in Existing Endpoints

GET Sales

GET Products

GET ClientVisits

GET Clients

April 2021 Updates - New Endpoints

Exciting news! We have introduced 4 new endpoints in Public API. Do check them out.

GET Categories

GET Transactions

GET ClientCompleteInfo

GET PaymentTypes

GET ProductsInventory

February 2021 Updates - New endpoints

Exciting new endpoints are available in Public API!

POST AddStaff

POST UpdateStaff

POST AddPromoCode

GET PromoCodes

Upcoming site maintenance

We’re upgrading the servers that power Booker to AWS, providing you with industry leading security and uptime. Scheduled downtime will occur on Sunday, February 21 from 1:00-5:00AM EST while we complete this upgrade.

SCA Regulatory Updates

Strong Customer Authentication (SCA) is a new European regulatory requirement to reduce fraud and make online payments more secure. To accept payments and meet SCA requirements, we have made additions to the CheckoutShoppingCart, PurchaseContract, and PurchaseGiftCard endpoints to facilitate an SCA challenge. This only impacts EU customers who use the Public API to conduct consumer transactions using Stripe.

New optional request fields that have been added:

• ConsumerPresent (Boolean) - Use this to indicate that the consumer is present or otherwise able to successfully negotiate an SCA challenge. It is not a good idea to have this always be false as that could very likely lead to a bank declining all transactions for the merchant. Defaults to false.
• PaymentAuthenticationCallbackUrl (String) - If ConsumerPresent is true, and the bank requests SCA, upon completion of the SCA challenge, the consumer will be redirected back to this URL. Unfortunately, at this time there is no indication as to whether the consumer confirmed or denied the transaction. This field is only needed if ConsumerPresent is true.
• CheckoutShoppingCart only: TransactionIDs (List of integers) - If any of the credit card payments are indicating an SCA challenge, then a second call into CheckoutShoppingCart is required where these challenged or pre-authorized credit card transactions will be needed to complete the process and capture the funds. These will be provided to you in the response from the first call to CheckoutShoppingCart along with AuthenticationUrls for any card authorizations that have an SCA challenge indicated. Note that if no SCA challenge is required, these will not be provided in the response and no second call into CheckoutShoppingCart is needed. Also note that this list may only contain 1 integer depending on whether your integration allows for multiple payments which is supported by the CheckoutShoppingCart endpoint.

One new element has been added to the CheckoutShoppingCart response object:

Transactions (List of TransactionResponse)

• TransactionID - integer
• AuthenticationUrl - string (optional valid URL provided by the bank)

If no SCA challenge is indicated, none of this information is needed and it will not be returned, and no 2nd call into CheckoutShoppingCart is needed. If provided at least one of the indicated transactions will have an AuthenticationUrl where the consumer will need to accept or decline the transaction, and upon doing so will be redirected to the PaymentAuthenticationCallbackUrl indicated in the request.

If your integration supports multiple credit card payments, there is a chance that more than one of them will have an SCA challenge indicated. It is up to your application to maintain this awareness and only make the 2nd call into CheckoutShoppingCart when all the challenges have been addressed.

Your integration will need to provide all these TransactionIDs in the 2nd call back into CheckoutShoppingCart. Any TransactionResponse indicating only a TransactionID with no AuthenticationUrl, simply means that transaction has been preauthorized and has no SCA challenge indicated.

One new element has been added to the PurchaseContract/PurchaseGiftCard response object:

PaymentProcessingFailures (List of PaymentProcessingFailure)

• Type - string
• Message - string
• AuthenticationRedirectUrl - string (optional valid URL provided by the bank)

If no SCA challenge is indicated, PurchaseContract.Status = Success, none of this information is needed and it will not be returned, and no 2^nd call into PurchaseContract is needed. If provided at least one of the indicated PaymentProcessingFailures, will have an AuthenticationRedirectUrl where the consumer will need to accept or decline the transaction, and upon doing so will be redirected to the PaymentAuthenticationCallbackUrl indicated in the request.

Because PurchaseContract leverages a shopping cart via the Mindbody Marketplace, no additional information needs to be passed back in the 2^nd call into PurchaseContract to finalize the order. Note: The cart will only remain valid for 15 minutes, after which time the cart is abandoned and any authorized credit card transactions will be voided.

December 2020 Updates - GetClasses V6 Will Not Show Hidden Classes When Unauthenticated

Beginning mid-December, we will be providing more support for cancelled classes that are hidden from the schedule. GetClasses V6 will no longer return classes that are marked as "hidden" when there is no authentication header present (read more about hidden classes). Unauthenticated users should never have access to see these hidden classes.

Hidden classes will continue to be returned when a staff with valid permission is authenticated.

UPDATE:

This was released on 12/16/2020

Added Validation for Adding/Updating a Client's HomeLocation

The following client HomeLocation validation was added to match the current behavior in the core software:

When adding a new client using AddOrUpdateClients in v5.0 or v5.1 or AddClient in v6, if the HomeLocation property is not provided in the request, then the HomeLocation will be set to default to the first active location ID of the studio.

On update or add, if the HomeLocation ID is provided in the request, it must be a valid active location ID. Zero is also a valid value for HomeLocation ID on update or a staff-level add, which means "all locations" or "no preferred location".

Class/Enrollment Booking Endpoints V5.x + V6.0 Respects "Make Unpaid Reservation" Staff Permission

On 10/30/2020 at 10:00 AM PDT we released an update to the AddClientsToClasses, AddClientToClass, and AddClientsToEnrollments endpoints in V5.x + V6.0 which affects whether staff can create an unpaid class reservation.

When the Make Unpaid Reservation staff permission is disabled for the User Token or User Credentials supplied in the request, then the endpoint will return the following error:

Staff member does not have permission to make unpaid reservations.

If this permission is enabled, the staff will be allowed to complete the unpaid reservation successfully. This functionality now matches that of our core web software.

Please note that all staff members that do not have this permission will experience a change in behavior and will no longer be allowed to make unpaid reservations.

Get ClassDescriptions V6 Update to Fix Duplicate Results

On 10/26/2020 we released an update to the Get ClassDescriptions V6 endpoint. Now when providing a date filter in the request we return one ClassDescription object per Class. The old behavior would return a ClassDescription object for each scheduled occurrence of the Class in the date filter range.

GetClasses V6 Update to Respect Consumer Mode Show Open Class Spaces Setting

On 10/13/2020 at 10:00 AM PDT we released an update to the GetClasses endpoint in V6 which affects whether class capacity properties are returned based on authorization and a class setting.

When the General Setup & Options - Consumer Mode Show # Open Class Spaces setting is disabled and no User Token is included in the request Authorization header, then the following class capacity properties will be returned as null in the response:

• MaxCapacity
• TotalBooked
• TotalBookedWaitlist
• TotalWebBooked
• WebCapacity

If this setting is enabled, the properties will be returned. If a user token is passed that was generated using Staff level credentials or higher (or using Source Credentials), then the class capacity properties will always be returned regardless of the setting, which applies to consumer mode only. This functionality matches that of previous versions of the API.

Developer Portal Sign-in Upgrade

On 10/10/2020 at 9:00 PM PDT Mindbody will be upgrading the sign-in workflow for the Developer Portal, so you can authenticate using a single Mindbody account. If you've downloaded and signed up for the Mindbody app, good news—you already have a Mindbody account!

If your existing Mindbody account uses the same email you have on file with the Developer Portal, please use your Mindbody account password to sign in after the upgrade.

If you do not already have a Mindbody account for the email you have on file in the Developer Portal, one will be created for you as part of the upgrade. You will then be asked to verify your email address upon your next sign in.

We recommend taking the time to ensure your Developer Portal account information is up to date to avoid any potential sign-in confusion.

August 2020 Updates - Create/Delete Appointment Add-Ons and Webhooks

August brought us the ability to create or delete add-ons for an appointment, as well as created/deleted webhooks for add-ons.

Post AddAppointmentAddOn

Delete DeleteAppointmentAddOn

New appointmentAddOn.created Webhook Added!

New appointmentAddOn.deleted Webhook added!

July 2020 Updates - Updated Staff Endpoints, Get Add-Ons, And Get Available Dates

July brought us a workflow optimization to check on scheduled availability for up to a 30 day range for a specific type of appointment, as well as expanded visibility into and information regarding add-ons.

Get Staff

Get AppointmentAvailableDates

Get AppointmentAddOns

Get StaffAppointments

Live Stream Classes Are Here!

Mindbody's Virtual Wellness Platform is a fully integrated video on-demand and live stream platform enabling businesses to create sustainable, hybrid business models with virtual offerings directly through the Mindbody business software. Consumers will now be able to book, pay for and experience virtual classes and wellness services through one application.

We added a ContentFormats property to the Program shared resource returned from Public API V6 endpoints. Possible values:

1. "InPerson" - The program does not offer virtual classes.
2. "LiveStream:Mindbody" - The program offers classes with virtual live streams hosted on the Mindbody Virtual Wellness Platform.
3. "LiveStream:Other" - The program offers classes with virtual live streams that are not hosted on the Mindbody Virtual Wellness Platform.

We added a VirtualStreamLink property to the Class shared resource returned from Public API v6 endpoints. This URL is only returned for Classes that:

1. Offer virtual live streams hosted on the Mindbody Virtual Wellness Platform and
2. have not yet started

Live stream links are usually generated the day of the scheduled class.

May 2020 Updates - Addressing Duplicate Client Creation in Public API

Starting the week of May 18th, 2020 all versions of the Public API will no longer allow duplicate clients to be created. Duplicate client accounts are a commonly referenced issue that will be addressed in upcoming changes to the Public API. In the future, duplicate clients will no longer present issues for your integration as we change our API responses to better serve your needs.

Duplicates are defined as client records with the same first name, last name and email.

MINDBODY recommends updating integrations to handle these new error responses when using AddOrUpdateClients, AddClient or UpdateClient across Public API V5.0 through V6.0. In V5.0 and V5.1 error codes will be returned in the 300s range with a message indicating duplicate creation was attempted. In V6.0 an HTTP Status Code 400 and error message will be returned

If you are a business that would like to use this update earlier than May, please contact your account manager or the Contact API Support.

Duplicates FAQ

• I need to be able to make duplicate clients, what do I do now? Can an exception be made for my account so I can make duplicate clients?
  • Tell Contact API Support your use case(s) and feedback will be collected for the product and engineering teams to review.
• I already have duplicates in my site, what happens now? Can I make edits to these profiles?
  • You can still make edits to profiles that involve existing duplicates, however we recommend updating these profiles later using the Merge Duplicate Clients tool.

• What error responses can I expect to see if I attempt to make a duplicate?
  • In Public API V5.0 and V5.1 when calling AddOrUpdateClients and attempting to create a client with the exact same email, first and last name as an existing client profile at the studio will return an error code "331" and error message "Client creation cannot result in duplicate client records".
  • In Public API V5.0 and V5.1 when calling AddOrUpdateClients and attempting to update a client with the exact same email, first and last name as an existing client profile at the studio will return an error code "332" and error message "Client update cannot result in duplicate client records".
  • In Public API V6.0 when calling AddClient and attempting to create a client with the exact same email, first and last name as an existing client profile at the studio will return HTTP Status Code 400, an error code "InvalidClientCreation" and error message "Client creation cannot result in duplicate client records.".
  • In Public API V6.0 when calling UpdateClient and attempting to update a client profile with the exact same email, first and last name as an existing client profile at the studio will return HTTP Status Code 400, an error code "InvalidClientUpdate" and error message "Client update cannot result in duplicate client records.".

Public API V6.0 POST AddArrival Updates

Cross-regional arrivals are now supported in V6.0! When used on a site that is part of a region, the following new logic will apply:

• When a client exists within the region but not at the studio where the arrival is being logged, a local client record will be automatically created.
• If the local client does not have an applicable local membership or pricing option, a membership or pricing option will be automatically used if it exists elsewhere within the region.

Developers calling POST AddArrival V6.0 must provide a staff user token with staff assigned the LaunchSignInScreen permission. Anonymous calls to AddArrival V6.0 will fail with the error message "Authorization Required".

Public API V6.0 GET Services Updates

We have recently added some additional properties to the GET Services endpoint to help improve your purchase workflows. Changes include "SellOnline", "Membership" and "IsIntroOffer". Find out more in the documentation here.

Past and Upcoming Bug Fixes - Public API & Webhooks

Week of March 30th, 2020 - Tentatively Planned For

• A new endpoint GET ClientDuplicates will be available in Public API V6 to check for duplicate clients.
• Developers using UploadClientPhoto will no longer experience outdated images returned in the GET Clients response.
• Developers will receive documentation for new endpoints GET Genders and GET ClientDuplicates.
• Developers will no longer see code examples with `http`, which has been updated to `https`.
• Developers will see an updated list of error codes found in versions 5.0 & 5.1.

Week of March 23rd, 2020

• Developers calling POST AddClient V6.0 will no longer receive a false error when attempting to add a new client to a new site with no clients.
• Developers calling POST AddAppointment and UpdateAppointment will now be informed when attempting to use an unrecognized gender preference.
• POST AddAppointment will no longer throw a 401 error when attempting to send a booking confirmation email.
• Developers will be able to add custom gender values for V6.0 POST AddClient, V6.0 POST UpdateClient, V5.x AddOrUpdateClient, and V5.1 UpdateClientCrossRegional. 
• Developers will now be able to view all previous release note entries. Scroll through prior notes below.

Week of March 16th, 2020

• In Public API V6.0 when using POST PurchaseGiftCard using the Test flag and then attempting to make a live sale will no longer error. 
• Customers using the Developer Portal for Public API will see (1) a minor update to the cross-regional usage tutorial, (2) a minor correction to the Handling Errors section of the V6.0 documentation, and (3) a new button that allows a client to download the Public API Postman collection. 

Week of March 9th, 2020

• In Public API V5.x when using AddOrUpdateClients we will now require the use of an email when adding a new client or updating a client profile and are checked under the Required Fields. This will apply to both consumer mode and staff mode requests.

Week of March 2nd, 2020

• In Public API (all versions) when using GetClientVisits we fixed an issue where arrival visits were not returned in the response.
• In Public API (all versions) when using GetClientVisits we fixed an issue where duplicate appointment visits were returned in the response. 
• In Public API V6.0 when using AddAppointment or UpdateAppointment and "GenderPreference" parameter is left out or set to "None", the preference will be set to No Preference.  

Recent Webhooks Updates

We have recently added some additional properties to the Webhooks client, classRosterBooking, class and classSchedule payloads to help improve your class booking experiences. 

• The client payloads have been updated to now return you details on billing info, client photos and prior email addresses used for client records. These are great pieces of information to use when building a comprehensive profile overview for your integration.
• The classRosterBooking payloads now include item details so you can relate these back to the Services[].ProductId returned by GET Services in Public API. This is helpful if you would like to see what services a client used during their booking. 
• The class and classSchedule payloads have been updated to now include details for assistants assigned to classes. In addition, the classSchedule payload has been updated to now only send when a change is made to the entire schedule. If you had previously used this to indicated single class instance changes please use the class.updated Webhook instead. This includes class cancellations. 

Developer Onboarding Changes - February 2020

Starting February 19, 2020 all Developer Accounts created on that date or after will be unable to use Public API V5.0 or V5.1. All developers are encouraged to use V6.0, which is MINDBODY’s latest release of the Public API. Existing accounts will not be affected by this change.

Onboarding FAQ

• How will I know if I cannot use Public API V5.0/V5.1?
  • You will know if your account does not have access if it was created on or after February 19, 2020 or receives error code 108 and message "Your developer account does not have access to this legacy version".
• I need something that is only in V5.0/V5.1, what do I do now?
  • Tell Contact API Support and feedback will be collected for the product and engineering teams to review.
• Can an exception be made for my account so I can use V5.0/V5.1?
  • Tell Contact API Support and feedback will be collected for the product and engineering teams to review.
• Does this mean V5.0 and/or V5.1 is being deprecated?
  • This is not a deprecation announcement for V5.0 and V5.1 of the Public API. When that happens, a broad announcement will be made that is clear on timelines and changes regarding deprecation plans.
• Why are you stopping onboarding to V5.0/V5.1?
  • V6.0 of the Public API has been in stable release for close to a year and based on feedback and adoption rates we feel it is time to move all new developers to the latest version where stability, security and ease of use are much greater.
• What should I do if I'm currently using V5.0/V5.1?
  • We recommend all developers regularly plan to update their integrations to MINDBODY, but also recognize this can be a large change so at this time we will continue to provide support for our V5.x users.
• How can I find the V5.0/V5.1 documentation if I can no longer pick the version of documentation to view?
  • Please login to your account and the option to view the documentation will be available. Alternatively, you can use this link to view after logging in.

Addressing Duplicate Client Creation in Public API

Changes were made as of February 28, 2020 to projected error codes. Error 329 will now be 331, and error 330 will be 332. The requirement of email, first and last name on client creation and update has been removed and will use existing requirements for first and last name. Please account for these changes.

Duplicates FAQ

• I need to be able to make duplicate clients, what do I do now? Can an exception be made for my account so I can make duplicate clients?
  • Tell Contact API Support your use case(s) and feedback will be collected for the product and engineering teams to review.
• I already have duplicates in my site, what happens now? Can I make edits to these profiles?
  • You can still make edits to profiles that involve existing duplicates, however we recommend updating these profiles later using the Merge Duplicate Clients tool.

• What error responses can I expect to see if I attempt to make a duplicate?
  • In Public API V5.0 and V5.1 when calling AddOrUpdateClients and attempting to create a client with the exact same email, first and last name as an existing client profile at the studio will return an error code "331" and error message "Client creation cannot result in duplicate client records".
  • In Public API V5.0 and V5.1 when calling AddOrUpdateClients and attempting to update a client with the exact same email, first and last name as an existing client profile at the studio will return an error code "332" and error message "Client update cannot result in duplicate client records".
  • In Public API V6.0 when calling AddClient and attempting to create a client with the exact same email, first and last name as an existing client profile at the studio will return HTTP Status Code 400, an error code "InvalidClientCreation" and error message "Client creation cannot result in duplicate client records.".
  • In Public API V6.0 when calling UpdateClient and attempting to update a client profile with the exact same email, first and last name as an existing client profile at the studio will return HTTP Status Code 400, an error code "InvalidClientUpdate" and error message "Client update cannot result in duplicate client records.".

November 2019 Updates - New Membership Features, Appointment Booking Updated Webhook & Much More!

November brought us even more updates to the API Platform. Check out the changes below and see what was released in the last month.

GET Memberships - New Endpoint

GET ActiveClientMemberships Public API V6.0 - Cross-Regional Lookups!

New appointmentBooking.updated Webhook Added!

Visit Resource Updates in Public API V6.0

Cross-Regional Waitlist Now Supported in V6.0

GET ClientServices now returns ProductId

October 2019 Updates

October was a busy month for our API Platform. Check out the updates below and see what was released in the last month.

Direct Debit/ACH Support in Public API V6.0 - Additional Payment Options for Checkout!

GET Sales Public API V6.0 Improvements - More Data and Service Mapping!

GET GiftCardBalance Public API V6.0 - Check Those Balances!

IP Whitelisting Available Now

Developers can now secure their integration with the MINDBODY Public API through the usage of IP Whitelists. This additional security measure gives developers an additional layer of protection when interacting with customer data. It is not mandatory to use, however it is highly recommended.

This is documented in the Developer Portal under the Authentication section.

The Stable Release of the Public API V6.0 is Here!

MINDBODY is happy to announce that Version 6.0 of the Public API is now stable and ready for use in your applications. Here are a few of the highlights of the new release.

Transitioning to RESTful APIs

New and Improved Documentation

Standardized Error Handling

Support for Gift Cards

• create a MINDBODY developer account use the MINDBODY sandbox for development and testing your application
• request approval from MINDBODY to take your application live
• once you're approved, follow the activation process to take your application live

Announcing the Stable Release of the Webhooks API!

As of April 1, 2019, MINDBODY proudly announces that our Webhooks API V1.0 release has been promoted to a Stable Release, ready for use in your applications.
You can use this API to create an application that shows near real-time updates to business data without having to long-poll the Public API. This API is MINDBODY's implementation of an HTTP push API. The MINDBODY Webhooks API notifies you when specific events that you subscribe to occur in the data of a business that uses MINDBODY.
For example, using the Webhooks API, you can create a subscription that notifies you as soon as a new client has been created so that your application can send the client a welcome email. Another typical use is to create a subscription that notifies you when a client has booked a class or an appointment, so that you can reduce the frequency of call volume.

Release Highlights

• API Key Updates
  You can now use the same API key mechanism for the Public API and for the Webhooks API. Create a key for each of your integrations on the API Credentials page in the Developers Portal and manage all your keys in one place.
• Authorization Updates
  Now that we have implemented API keys for Webhooks, the Authorization header is no longer required in calls.
• PATCH Subscription Endpoint
  We have added a new endpoint that lets you activate and reactivate the subscriptions that are associated with your developer portal account. You no longer need to contact MINDBODY to have this done for you. Note that you can only activate or update one subscription at a time using this endpoint.

Public API V6.0 now in Open Beta!

Check out the latest version of the Public API and explore all the new updates we've been making to the platform!

Highlights

• Transitioning to RESTful APIs
• Standardized Error Handling
• Detailed Documentation
• Gift Card Support
• And much more!

Disclaimer: You should expect releases that are labeled beta to have frequent, unannounced changes, so we recommend that you do not use beta features in your production offerings.

Please send all feedback to Contact API Support

Watch the latest MINDBODY Developer Videos

BOLD 2018: Josh Lloyd on FitMetrix

At the Partner Track at MINDBODY BOLD 2018, Josh Lloyd (FitMetrix) explains how to create a fantastic API integration. Watch it here.

API Keys - MINDBODY

How to use API keys on the MINDBODY Public API. Watch it here.

API Updates 6/14/2018

GDPR

The v5.0 and v5.1 GetClients endpoint has been updated to return email opt-in statuses to meet new GDPR requirements. The GetClients output has not changed, it will still return:

• PromotionalEmailOptIn for newsletters and marketing campaigns 
• EmailOptIn for scheduling notifications and reminders

Please note GetClients has not been updated to include SMS opt-in statuses, this work will be completed during a later phase. We recommend calling GetClients to refresh your data-caching layer if you have not done so since June 13, 2018.

Deprecation of TLS 1.0 and 1.1 Support

On June 18th, 2018, MINDBODY will no longer accept connections made over TLS 1.0 or TLS 1.1. MINDBODY will only accept TLS 1.2. You may have to change the code in your API integration to accommodate this security change. This update is mandatory, as MINDBODY must be PCI compliant.

The Payment Card Industry (PCI) Data Security Standard has stipulated that TLS 1.0 and 1.1 encryption protocols can no longer be used for secure communications, only TLSv1.2 or higher is acceptable. The PCI DSS standards can be read in full here.

To ensure compliance with the PCI DSS standards and security best practices, MINDBODY will disable support for TLS 1.0 and 1.1 on all our web-facing systems on Monday June 18th, 2018. After June 18, 2018, MINDBODY Partners who attempt to access the MINDBODY platform with TLS 1.0 and 1.1 will have their connection refused, only TLS 1.2 will be accepted.

If your requests to MINDBODY use TLS 1.0 or 1.1 your automation will need to be updated to exclusively use TLS 1.2. This may involve updating your programming language or tool set to a more modern version, or changing configurations to specifically enable TLS 1.2 and disabling TLS 1.0 and 1.1. If you do not make this change you will not be able to access the MINDBODY API platform.

If your requests to MINDBODY already use TLS 1.2, no change is needed.

If you have questions, please Contact API Support.

Thank you for working with us to keep our shared customers safe.

The MINDBODY Team

API Updates 5/30/2018

SOAP API Version 5.1 Promotion to Stable Release

We are pleased to announce that Version 5.1 of our SOAP API has been promoted to Stable Release. We now recommend developers use v5.1 in their production applications.

API Updates 1/18/2018

Beginning 1 January 2018, any business subject to French taxation is also subject to the new French NF525 law that requires businesses that record payments via a cash drawer, accounting or management software, to use a software which meets certain conditions of sales data inalterability, security, storage and archiving.

To allow for compliance with the NF525 law, certain functionality related to editing of sales has been removed from UpdateClientServices and UpdateSaleDate in version 5.0 and 5.1 for MINDBODY businesses located in French territories. Developers will now be returned the following response:

<Status>InternalException</Status>
<ErrorCode>1100</ErrorCode>
<Message>Endpoint not accessible for the subscriber's country</Message>

If you have any questions, please contact us at [email protected].

API Updates 9/26/2017

SOAP API Version 5.1 (beta) Released

We are pleased to announce that Version 5.1 of our SOAP API has been released. This update contains support for many Cross-Regional use cases, as well as Contracts/Autopays. As a beta release, feel free to begin starting with your dev/test efforts. We are actively collecting feedback at Contact API Support. However, we do not recommend using these new features for production use until we make a GA release.

Getting Started with Version 5.1 (beta)

Switching to version 5.1 is simple. Wherever you are using /api/0_5 in your API calls, use /api/0_5_1 instead. This is relevant for accessing all routes (WSDL, SOAPAction, etc.).

Example: https://api.mindbodyonline.com/0_5/ClientService.asmx?wsdl
Becomes: https://api.mindbodyonline.com/0_5_1/ClientService.asmx?wsdl

API Support for Contracts/Autopays with Credit Cards

• The Sale Service now has two new endpoints: GetContracts and PurchaseContracts.
• GetClientContracts, part of the Client Service, has been updated to include additional information about clients' previously purchased contracts.

Cross-Regional Class Bookings

• The Class Service has been updated with a new endpoint, AddClientToClass, which now supports Cross-Regional class bookings.
• When used on a Cross-Regional class booking, RemoveClientsFromClasses has been updated to return sessions back to the series (ClientService) that was used to book into a class.

Cross-Regional Client Lookups

• GetClientServices
• GetClientSchedule
• GetClientVisits
• GetClientContracts

Cross-Regional Client Updates

• Do you need to update client information (based on RSSID / ClientID) across all of the sites within a Cross-Regional Organization? Now you can using UpdateClientCrossRegional

Updates to Additional Endpoints

• GetSales now returns the ClientID associated with a sale, as well as information about the items associated with the sale.
• GetClients now allows you to pass in a LastModifiedDate which, when set, will result in only clients who have been modified on or after the specified date being returned in the response.
• GetClasses now allows you to pass in a LastModifiedDate which, when set, will result in only classes that have been modified on or after the specified date being returned in the response.
• GetClassVisits now allows you to pass in a LastModifiedDate which, when set, will result in only visits that have been modified on or after the specified date being returned in the response.

API Updates 6/19/2017

Upcoming Changes to Version 5.0

Within the next 4 weeks we will be making several improvements to various methods within our SOAP API. Here is a list of upcoming updates:

GetClients

Summary: The response for GetClients is being updated to more closely resemble the information that a staff member can see within our core software. Currently, when developers execute a GetClients request with a Fields.Clients.ClientCreditCard and staff credentials of a staff member that has the “View client billing information” permission enabled and the “View client profile” disabled , the credit card property is returned in the response. However, this same staff member is not able to view the clients stored credit card in through core. Updated Behavior:

• If “View client billing information” is enabled and “View client profile” is disabled, then the response will not contain credit card response properties.
• If “View client billing information” is disabled and “View client profile” is disabled, then the response will not contain credit card response properties.
• If “View client billing information” is enabled and “View client profile” is enabled, then the response will contain credit card response properties.

AddOrUpdateAppointments

Current Behavior: When developers execute an AddOrUpdateAppointments request to update an existing appointment using staff credentials that do NOT have the “Modify appointments” permissions enabled, the Response.ErrorCode is set to ‘200’ with a Response.Status of ‘Success’. The message within the <Appointments> response property correctly displays “Permission error - User does not have permission to edit appointment.”

Updated Behavior: When user executes an AddOrUpdateAppointments request to update an existing appointment using staff credentials that do NOT have the “Modify appointments” permissions enabled, the Response.ErrorCode is set to ‘201’ with a Response.Status of ‘FailedAction’. The message within the <Appointments> response property correctly displays “Permission error - User does not have permission to edit appointment.”

GetActiveClientMemberships

Current Behavior: This method only returns the most recent membership that a client has even though the client has more than 1 active memberships. Updated Behavior: We will be updating the behavior of this method and returning all client active memberships and not just the most recent membership.

GetStaffAppointments

Current Behavior: Appointments scheduled on "All/Business Closed" holidays are returned in the GetStaffAppointments response. However, our core software does not allow staff to view these appointments from the in the appointment schedule screen and instead displays the holiday message. Updated Behavior: The GetStaffAppointments response will not display any appointments that are scheduled on a "All/Business Closed" holidays.

API Updates 5/26/2017

Within the next 4 weeks we will be making several improvements to various methods within our SOAP API. Here is a list of upcoming updates:

• AddClientsToClasses
  • Developers were experiencing an edge case where users could be added to classes even if the classes were full. This has been resolved.
• AddOrUpdateAppointments
  • The behavior of this method has been fixed to allow for the late cancelling of appointment requests. This error message will be replaced with a “200 Success: Appointment.Action.Updated” status in the response.
  • Some developers were reporting issues when updating the StartDateTime of existing appointments. These issues have been resolved.
  • Scheduling restrictions for businesses that use the “Scheduling Suspension” feature have been updated to be consistent with how our core software works.
  • Previous Behavior: When user executes an AddOrUpdateAppointments request to update an existing appointment using staff credentials that do NOT have the “Modify appointments” permissions enabled, the Response.ErrorCode is set to ‘200’ with a Response.Status of ‘Success’. The message within the <Appointments> response property correctly displays “Permission error - User does not have permission to edit appointment.” Updated Behavior: When user executes an AddOrUpdateAppointments request to update an existing appointment using staff credentials that do NOT have the “Modify appointments” permissions enabled, the Response.ErrorCode is set to ‘201’ with a Response.Status of ‘FailedAction’. The message within the <Appointments> response property correctly displays “Permission error - User does not have permission to edit appointment.”

API Updates 5-25-2017

SOAP v.5 – ClassService.GetClasses

• A bug in our latest update of this method was causing classes scheduled on holidays / closed days to be returned in the response of Get Classes. With a release happening on 5/25/2017, this issue will be resolved and those classes will no longer be included in the response object.
• When a user passes in a <PageSize> value of ‘0’, the GetClasses response will contain all classes within the supplied request parameter range.
• GetClasses will now return valid resource information for each class returned in the response. Please note that resource information will only be returned when the Classes.Resource field request parameter is included in the GetClasses request.

API Updates 4-19-2017

SOAP v.5 – ClassService. AddClientsToClasses

• Method updated to check against the "Scheduling Suspensions" site setting when a attempting a consumer booking for accounts with a contract suspensions on file.

SOAP v.5 – ClassService.AddClientsToEnrollments

• Method updated to check against the "Scheduling Suspensions" site setting when a attempting a consumer booking for accounts with a contract suspensions on file.

SOAP v.5 – AppointmentService.AddOrUpateAppointments

• Method updated to check against the "Scheduling Suspensions" site setting when a attempting a consumer booking for accounts with a contract suspensions on file.

SOAP v.5 – SalesService.CheckoutShoppingCart

• Method updated to prevent deactivated pricing options from being purchased.

SOAP v.5 - ClassService.GetClasses

• Method has been optimized to reduce network strain and improve processing times. As part, the following changes have been introduced:
  • Update to return classes with service categories set to “inactive”.
  • Update to return deactivated resources still assigned to active classes.
  • Update to return ‘Substitute=False’ when assigned class has been cancelled.
  • Update to return staffID of originally scheduled staff member for cancelled classes. This is a change from previous behavior of staffID being returned as “-1”.
  • Method no longer requires “Classes.Resource” to be passed in request to return resources/room information. Instead the ‘Resource’ object will now be returned by default for requests using “XMLDetail=Full”.
  • Update to no longer return an error for requests including an inactivate ‘LocationID’.

SOAP v.5 – ClientService.GetClients

• Fix to resolve issue with the following error being thrown when requesting client relationships: [Incorrect syntax near ')'.]

SOAP v.5 - ClassService.RemoveClientsFromClasses

• Fix to resolve issue with "Waitlist Notification" sms messages not being sent to clients added to class roster following client cancellations through the API.

SOAP v.5 – ClassService.UpdateClientVisits

• Fix to resolve issue with "Waitlist Notification" sms messages not being sent to clients added to class roster following client cancellations through the API.