Mindbody Php Api Laravel Package

Getting Started

The package is a thin PHP wrapper around Mindbody's SOAP API — not a full SDK. Expect to write raw SOAP-style calls against methods that mirror Mindbody's published service operations, with the wrapper handling WSDL, auth headers, and payload assembly for you.

1. Install

   composer require devincrossman/mindbody-php-api
   

   Ensure the PHP soap and libxml extensions are enabled — the wrapper cannot function without them.

2. Collect credentials before writing code. Mindbody issues three things you'll need: a Source Name, a Source Password (the API key tied to that source), and a Site ID for the studio you're integrating. Without a provisioned source, every call fails at auth.

3. Look first at the class constructor and its configuration properties. The wrapper's public surface is essentially: set source credentials, optionally set staff user credentials (many operations require a staff account bound to the site, not just source auth), then call methods like GetClasses, GetClassSchedules, GetStaff, GetClients, AddClient, GetServices, GetSites. Skim the Mindbody SOAP service docs alongside the wrapper — the method names map 1:1.

4. First use case: pull a class schedule. Configure credentials → call GetClasses or GetClassSchedules for a date range → iterate the returned SimpleXMLElement results. This is the lowest-friction operation because it typically only needs source credentials.

5. Start against Mindbody's sandbox/site, not production, while you learn response shapes. Log the raw XML of every response during development — the structure varies by operation and is not normalized.

Implementation Patterns

Wrap it in a service class of your own. Don't let the wrapper leak into controllers. Build a MindbodyClient adapter that instantiates the package class once, injects credentials from config/env, and exposes typed methods (getClassesByDate, bookAppointment) that return plain arrays or DTOs instead of SimpleXMLElement. The wrapper is stateful and credential-bound — treat it as an infrastructure dependency.

Normalize responses at the boundary. The wrapper hands back XML-backed objects. Convert to arrays once, in your adapter, and cache the parsed result. Downstream code should never call ->xpath() or chase namespaces.

Cache aggressively. Mindbody SOAP calls are slow and rate-limited. Class descriptions, services, staff, and sites change far less often than schedules. Use Laravel's cache (or PSR-16) with operation-specific TTLs: hours for GetClassDescriptions/GetServices, minutes for GetClassSchedules, near-real-time only for bookings and client mutations.

Separate read and write flows. Schedule/client reads can be retried and cached freely. Writes (AddClient, AddAppointment, BookClass) must be treated as non-idempotent — gate them behind a job, log the request payload, and reconcile failures against Mindbody state before retrying.

Queue anything that mutates or loops. Sync jobs that enumerate clients or pull 30 days of schedules belong in a queued job with backoff. A single long-running request against a 500-person client list will hit timeouts and throttling.

Environment-switch the WSDL base. Keep sandbox and production endpoints and credentials in distinct config keys, and select by APP_ENV. Never hardcode the production site ID in source.

Gotchas and Tips

• SOAP is the biggest hurdle, not PHP. If soap isn't compiled in, you'll get confusing fatal errors. Verify with php -m | grep soap before blaming the package.
• Auth confusion is the #1 support issue. Source credentials authenticate your application; staff credentials authorize actions on a specific site's data. Many methods need both, and error messages from Mindbody are notoriously unhelpful — an "invalid credentials" often actually means "missing staff user on this site."
• WSDL fetches are slow and cache-busting. Enable WSDL caching in php.ini (soap.wsdl_cache_enabled=1) — otherwise every instantiation re-downloads the WSDL. In CI, pre-warm or cache it explicitly.
• Responses are SimpleXMLElement. Empty result sets, single-result vs. multi-result responses, and attribute-vs-node data all behave differently. Write small helpers to detect emptiness and iterate consistently; don't assume results->Classes->Class is always an array.
• Time zones and site time will bite you. Mindbody stores times in the site's local zone, not UTC. Normalize before storing (Carbon setTimezone), and pass dates in the format the operation expects — date-only ops and datetime ops differ.
• Rate limits and timeouts. There's no built-in retry or rate limiter in the wrapper. Add your own throttle (e.g., a token bucket or RateLimiter) and wrap calls in a retry-with-backoff for transient SOAP faults, but never auto-retry writes.
• Debugging tip: log the full outbound XML and the raw response string before parsing. When the wrapper throws an opaque fault, that XML is the only way to see what Mindbody actually returned.
• Extension points are thin. The wrapper isn't designed for subclassing into a rich client. If you need custom headers, logging hooks, or fault interception, wrap the instance rather than extend it — or drop down to a direct SoapClient for edge operations the wrapper doesn't expose.
• Version pinning. With a single-maintainer wrapper, pin the version in composer.json and review the class before upgrading; breaking changes to method signatures or return handling can land without major-version bumps.
• Mindbody is migrating to REST. Treat this SOAP wrapper as legacy-compatible infrastructure. Isolate it behind your adapter so a future swap to the REST API is a one-class change, not a codebase-wide refactor.