- Is devincrossman/mindbody-php-api a Laravel package?
- No. It is a plain PHP wrapper class around the MINDBODY SOAP endpoint, with no service provider, facade, config file, or contracts. In a Laravel app it installs as a vendor dependency you would call directly, so the usual advice is to hide it behind your own adapter so it stays replaceable. The blurb mentions Laravel integration, but the package itself ships no framework-native wiring.
- How do I install devincrossman/mindbody-php-api with Composer?
- Install it as a normal Composer dependency with composer require devincrossman/mindbody-php-api, and make sure the ext-soap extension is enabled in every environment, including CI and production containers. There is no auto-discovery or publishable config, so nothing else is registered for you. Verify the repository is publicly reachable and check the commit history before adding it to composer.json.
- How do I configure MINDBODY API credentials in Laravel?
- Because the package has no Laravel config file, you must put your source credentials, staff user credentials, and site ID into config/services.php and your env file yourself, then pass them into the wrapper from your own service provider. Never hardcode them in controllers or commit them. If you wrap the client behind an interface, credential handling stays in one place and is easy to rotate.
- Does this package support PHP 8 and current Laravel versions?
- There is no evidence of a test suite or verified PHP 8 compatibility, so treat PHP 8.x support as unconfirmed until you run it in a spike. The package targets SOAP via ext-soap, which is language-level and not tied to a Laravel version, so it should load in modern Laravel. Validate it against your exact PHP and Laravel versions before relying on it.
- Does this wrapper use the MINDBODY SOAP or REST API?
- It wraps MINDBODY's SOAP endpoint using a WSDL, so every call is a SOAP request with XML envelopes and SOAP faults rather than HTTP status codes. MINDBODY's public API strategy has moved toward a REST and OpenAPI v6 surface, which makes this a legacy-era wrapper. Confirm with MINDBODY whether SOAP still covers your specific endpoints before committing.
- Can I use it to query class schedules, appointments, clients, and staff in Laravel?
- Yes in principle, since the wrapper exposes the scheduling, class, appointment, client, and staff endpoints of the MINDBODY API. In practice, start with a single low-risk read path such as class schedules or a client lookup behind a feature flag, and add write paths like bookings or client creation only after you have validated error handling. There is no typed API surface, so mistakes fail at runtime rather than at analysis time.
- How should I integrate this MINDBODY wrapper into a Laravel codebase?
- Do not call the wrapper class from controllers or jobs. Define an application-owned interface such as a MindbodyClient contract, bind an adapter implementation in a service provider, and add a fake implementation for tests. That keeps the third-party SOAP detail as an infrastructure concern and makes it swappable if you later move to MINDBODY's official SDK or a generated REST client.
- Does the package handle authentication, session expiry, retries, and timeouts?
- No. Authentication is your responsibility: source credentials plus staff user credentials plus the site ID, with SOAP faults surfaced instead of HTTP codes. WSDL fetching, local WSDL caching, token or session expiry, retry policy, and timeouts are all on you or on your adapter. Plan to add PSR-3 logging, typed exceptions, and a timeout and retry policy in the wrapper layer.
- Is devincrossman/mindbody-php-api safe to use in production?
- Treat it as high risk. It is a bus-factor-of-one dependency with a small star count, no evident release cadence, and no security response path, and it depends on a legacy SOAP API that MINDBODY could restrict or sunset. It can be used in production only behind your own contract, with WSDL caching, logging, and error handling you control, and with a documented plan to replace it.
- What are the alternatives to this MINDBODY PHP package?
- Evaluate MINDBODY's official SDK or a generated REST client for API v6 first, and if v6 covers your endpoints, skip this package entirely. If you must stay on SOAP short term, fork or vendor the class and add typed exceptions, PSR-3 logging, and local WSDL caching. Either way, implement the same internal contract so the underlying library remains replaceable.