- What is shelfwood/php-pms-clients and what does it do?
- It is a Composer-installable PHP client library that wraps property management system (PMS) APIs behind a single, consistent interface. Instead of writing separate HTTP code for each vendor, your Laravel or plain PHP app calls one unified API to sync reservations, availability and related resources. The package is aimed at hospitality integrations where operators run a PMS alongside a channel manager or a second PMS. The practical benefit depends on how much vendor-specific behaviour the shared contract actually normalises.
- How do I install shelfwood/php-pms-clients in a Laravel application?
- Install it with composer require shelfwood/php-pms-clients. In Laravel you would typically expect service provider auto-discovery plus a publishable config file for provider credentials, so run php artisan vendor:publish to push the config into config/php-pms-clients.php. Because the package is early stage and has no README documentation yet, read the source to confirm the exact config keys, service provider name and expected environment variables before wiring it in. Resolve clients from the container rather than instantiating them directly, so you can swap implementations later.
- Which property management systems does the package support?
- The package is built around multiple PMS providers, with Mews and Booking Manager being the two named in the technical assessment. Each provider gets its own client, while a shared layer is intended to give you a common way to fetch reservations, availability, rates and property details. Vendor support is limited to the endpoints the author has implemented, so verify that the specific resources you need, such as guests, rate plans or write operations, are actually covered before committing. Adding a new provider should mean writing one adapter rather than touching your domain code.
- Can I use shelfwood/php-pms-clients outside of Laravel, in queue workers or CLI commands?
- Yes, in principle. It is a PHP library delivered via Composer, so the clients should be usable anywhere PSR-18 or Guzzle HTTP clients work, including queue workers, artisan commands and scheduled jobs. The important caveats are that the HTTP client must be injectable rather than hard-coded, and that authentication token state must survive between jobs if you rely on a shared token store. Confirm both by inspecting the constructor signatures of the vendor clients before you build on them.
- How does the package handle authentication for each PMS provider?
- Each PMS uses a different auth model, and Mews in particular relies on token acquisition with expiry and refresh, while Booking Manager uses key-based credentials. A well-built multi-vendor client should encapsulate token lifecycle, including automatic refresh and re-authentication after a 401, so your application code never deals with access tokens directly. Whether this package fully owns that lifecycle is the key thing to verify. If it does not, you will be implementing refresh logic yourself, which is one of the main reasons to adopt a client library in the first place.
- Does the package handle retries, rate limiting, pagination and idempotency?
- These concerns are frequently left to the caller in packages of this kind, so treat them as unconfirmed until you check the source. Retries and backoff matter because PMS APIs will rate-limit you during busy sync windows, and pagination matters because reservation and availability listings are almost always paged. For write operations, idempotency is critical, since a retried create call must not produce duplicate reservations. If the package does not model these behaviours, plan to wrap it in your own gateway layer that does.
- How should I test code that depends on this package?
- The cleanest approach is to depend on your own PmsGateway interface rather than the vendor clients directly, then inject a fake implementation in unit tests. For integration tests, mock the underlying HTTP transport so no real PMS calls are made; this only works if the package accepts an injected PSR-18 or Guzzle client rather than constructing one internally. Recorded fixtures from a PMS sandbox are the most reliable way to catch payload-shape changes over time. Avoid tests that hit live vendor APIs in CI, because they are slow, credential-dependent and flaky.
- Is shelfwood/php-pms-clients ready for production use?
- Be cautious. The package has essentially no adoption signal, meaning zero stars, zero dependents and no third-party bug reports, which means its vendor API mappings have not been battle-tested against real payloads. Single-maintainer risk is significant, and error mapping from vendor error codes to typed exceptions is often the weakest part of libraries this young. The recommended pattern is to install it behind your own port interface and treat it as one adapter, so you can fall back to direct HTTP clients per vendor if the package stalls or is abandoned.
- How do I deal with vendor-specific differences and partial failures across multiple PMS providers?
- Normalise at the edges. Define your own domain terms, such as Reservation, Property and RatePlan, and map each vendor's payload into those shapes inside the adapter, keeping vendor fields out of your application code. Multi-vendor fan-out also introduces partial-failure semantics, where one provider succeeds and another fails, and this package probably does not model that for you. Wrap cross-provider operations in your own error handling that reports per-provider outcomes rather than a single success or failure. That way an outage at one PMS does not corrupt your sync state.
- Which PHP and Laravel versions does the package require, and what are the alternatives?
- Check the composer.json constraints for the minimum PHP version, Laravel service provider support and Guzzle or PSR-18 major version, because an incompatible Guzzle major will break your existing HTTP stack. If the package stalls, the alternatives are writing thin per-vendor HTTP clients behind your own interface, using the official vendor SDKs where they exist, or using a unified hospitality API aggregator. For a two-vendor integration, a hand-written adapter behind your own PmsGateway interface is a realistic fallback. Migrate one vendor at a time, starting with the better-documented Mews API, and leave the second on its existing path until the first is proven.