Tourcms Php Laravel Package

Product Decisions This Supports

• Self-serve customer onboarding. The new customer create and verify endpoints are the difference between “an ops person creates the customer record in TourCMS” and “the customer signs themselves up and books.” That unlocks a signup → verify → book funnel you can own in your product instead of routing through TourCMS admin, and it is the prerequisite for any gated-pricing, member-only, or post-purchase-account roadmap item.
• Build vs. buy for identity verification. Verification now exists as a first-class API primitive on the platform side. That removes “TourCMS can’t verify customers” from the build column and lets you buy the verification step rather than building a parallel identity store and reconciliation job.
• Integration resilience as a roadmap de-risker. The change to handle strings where the client previously assumed XML objects is a defensive fix against non-XML responses (HTML error pages, empty bodies, gateway timeouts). If your team has an open ticket about intermittent booking-flow failures with unhelpful exceptions, this release is likely the fix — deprioritize the custom retry/parser hardening you were scoping.
• Release cadence signal. Two feature-ish changes plus a hardening fix in one minor bump, with a first-time contributor landing an endpoint PR, suggests an actively maintained, contributor-friendly SDK. Reasonable evidence for “invest in this integration” over “wrap it ourselves.”
• Upgrade cost is low. Minor version, no deprecations, no breaking changes — a low-risk slot to schedule alongside existing work, not a project.

When to Consider This Package

Adopt (or upgrade to v4.10.0) when:

• You are on Laravel/PHP and TourCMS is the system of record for tours, availability, and bookings — the SDK is the intended path and reimplementing the API surface is wasted effort.
• You need customer creation and verification in-product, i.e. exactly what this release adds. If you were previously blocking a self-serve signup epic on “no verification API,” that blocker is gone.
• You want a maintained wrapper rather than owning auth, request signing, and response parsing yourself.
• You are already on 4.x — this is a drop-in minor bump; take it.

Look elsewhere or wrap defensively when:

• Your stack is not PHP/Laravel. This is a thin client, not a platform; there’s no reason to bridge it.
• You need capabilities the API still doesn’t expose — the SDK can only be as complete as the TourCMS API, and gaps become your problem.
• You require strong typing or generated clients from an OpenAPI spec. This release explicitly loosens type assumptions (strings in place of XML objects), which is pragmatic but means your own domain layer should validate and map responses rather than trusting shapes.
• You’re on a legacy TourCMS integration with heavy custom parsing — adopting this package means reconciling two parsing models; scope that before switching.

Upgrade guidance for this release: pin to v4.10.0, and add a test that feeds a non-XML error body through your booking path to confirm the string-handling change actually covers your failure mode rather than assuming it does.

How to Pitch It (Stakeholders)

To executives: This is a maintenance release that also closes a real product gap. We can now create and verify customers directly through the TourCMS integration instead of provisioning them by hand, which is what our self-serve signup and account-gated pricing work depends on. It’s a free upgrade with no breaking changes, so it’s low risk and unblocks roadmap work we’d otherwise have had to build or defer.

To engineering: Minor bump, no deprecations. Two things matter: (1) customer create and verify endpoints are now available in the SDK, so wire them into the signup flow rather than building against the raw API; (2) the client now tolerates string responses where it previously assumed XML objects, which should reduce flaky failures on error paths — validate this against our known intermittent failures before closing those tickets, and keep our own response mapping strict so the looseness doesn’t leak into the domain layer. Upgrade in the next maintenance window; no migration work expected. Isolate the SDK behind a gateway abstraction and add contract tests to contain future type changes.