Php Pms Clients Laravel Package

Product Decisions This Supports

• Feature: PMS connectivity for a hospitality/property product. If the roadmap includes syncing reservations, availability, rates, or property metadata with Mews or Booking Manager, this package is a candidate to shortcut the HTTP/auth/pagination plumbing that otherwise gets hand-rolled per vendor. The v5.0.0 release confirms it is tracking the Mews connector surface actively — availability, reservations, customers, and pricing are all in scope.
• Roadmap: multi-PMS abstraction strategy. It supports a "many PMS partners, one internal interface" architecture. The decision it informs is whether vendor-specific clients live behind our own adapter layer (recommended) or leak vendor concepts into domain code. This release is the argument for the adapter: Mews changed the availability request/response shape and endpoint path in a single major version, and that churn should stop at our interface boundary.
• Build vs. buy (adopt vs. build). The real comparison is not "free vs. paid" but "adopt a zero-adoption OSS client and own it" versus "write and maintain thin clients in-house." v5.0.0 sharpens this: the package now carries a versioned API upgrade tax (availability moved to 2024-01-22, reservations to 2023-06-06, customers reworked onto getAll + Extent + Limitation). Adoption is cheaper than building only if we also budget for absorbing vendor contract changes — which is the same work we'd do in-house, minus writing the transport layer.
• Multi-property correctness (new decision surfaced). Availability and pricing time-unit boundaries are now normalized to Mews-required "00:00 converted to UTC" using the enterprise timezone from configuration/get, cached per client instance. For a multi-tenant product this makes client-instance-per-enterprise an architectural requirement, not a detail. It also makes boundary correctness (DST, timezone changes on the enterprise record, cache invalidation) a product correctness concern for rates and availability — worth a written rule before any sync work starts.
• Time-to-integrate as a competitive lever. Faster PMS onboarding means faster property go-lives in sales. A reusable client lowers the marginal cost of each new PMS integration — but only if the upgrade path is owned by someone.
• Use cases: channel/rate sync, booking ingestion, property onboarding, integration spikes and POCs, and internal tooling where a full sync engine is overkill.
• Explicitly not supported: orchestration, webhooks, retry/idempotency policy, reconciliation, timezone/DST policy guarantees beyond Mews' boundary rule, or data normalization. Those remain product decisions we own regardless of what client we pick.

When to Consider This Package

Consider it when:

• The stack is PHP/Laravel and the target PMS is Mews or Booking Manager specifically — the package is narrow by design, not a general PMS layer.
• You need a thin client (auth, requests, response mapping), not a sync service.
• You are time-boxed on a spike or POC and want to validate a vendor's API surface before committing engineering effort. The v5.0.0 test fixtures are useful evidence of what Mews actually expects on the wire.
• You are prepared to vendor or fork it and pin the version. 0 stars, 0 dependents, and a single maintainer mean the bus factor is effectively one. v5.0.0 being a breaking major reinforces the rule: treat it as source you adopt, not a dependency you trust with a floating constraint.
• You can absorb breaking changes on the vendor's cadence. The release shows Mews versioned endpoints being adopted piecemeal; expect the next contract change to arrive as another major.
• Your tenancy model can give each enterprise its own client instance (required for the new timezone-cached boundary logic).
• Due diligence passes: open license, readable and tested code, coverage of the API version and endpoints you need, and sane error handling. Read the availability and pricing tests specifically — they are the assertions that encode the timezone/UTC behavior you'll be depending on.

Look elsewhere when:

• You need official, vendor-supported SDKs, an SLA, or a security/compliance sign-off — an unendorsed single-maintainer package will not survive that review.
• You cannot tolerate breaking changes without a maintained upgrade path. v5.0.0 is a hard migration for anyone on v4: request payloads, response mapping, and endpoint paths all moved.
• You need breadth: Apaleo, Cloudbeds, Opera, StayNTouch, or a normalized cross-PMS model. This is a per-vendor client, not an abstraction layer.
• You need behavior beyond transport: webhook ingestion, idempotent writes, backoff, queueing, conflict resolution. Building those on an unproven client increases, not decreases, total cost.
• You run a shared/singleton client across enterprises — the per-instance timezone cache makes that a silent correctness bug for availability and pricing.
• The team is not PHP/Laravel, or no one will own the fork and its upgrade path.
• The integration is trivial enough that a ~200-line in-house client is lower risk than an unproven dependency.

How to Pitch It (Stakeholders)

One line: A small, unproven open-source PHP client for Mews and Booking Manager that can remove weeks of plumbing from a PMS integration — but its new major release shows the upgrade tax is real, so it's worth an experiment, not a platform commitment.

For executives: This is a low-cost option on a narrow problem. It does not create vendor lock-in because we would wrap it behind our own interface and can replace it. The package has no adoption and one maintainer, and v5.0.0 was a breaking release that reworked availability, reservations, customers, and pricing against newer Mews endpoints — good evidence the maintainer is engaged, and equally good evidence that adopting it means owning a migration whenever Mews changes. Recommendation stands: a time-boxed spike, not a production dependency approved by default. Upside is speed to a working integration; downside is capped at the spike cost if we walk away.

For engineering: Adopt behind an internal PmsClient interface with our own DTOs, so vendor clients are swappable and testable. Fork it into our org, pin the exact tag, and add tests around the endpoints we actually use before it touches production. Two specifics from v5.0.0 to design around: (1) availability now requires Metrics and returns per-category Metrics maps — model that explicitly rather than passing it through; (2) availability and pricing boundaries are UTC-normalized from the enterprise timezone fetched via configuration/get and cached per client instance — so scope client lifetime to the enterprise, and decide how we handle timezone changes and DST. Budget for maintenance — nobody else is doing it.

Recommendation: Approve a 1–2 week spike against the specific PMS on our roadmap, pinned to v5.0.0, with a written go/no-go on code quality, endpoint coverage, error semantics, and the timezone/tenancy behavior above. Fund the adapter layer regardless of the outcome — that decision holds whether we fork this package, buy an SDK, or write our own.