Statamic Resrv Laravel Package

Product Decisions This Supports

• Customer-facing reservation lookup (affiliate/partner flows): The v6.4.0 fix makes reservationFromUri resolve partner (skip-payment) bookings, unlocking affiliate/white-label itinerary and confirmation pages that previously 404'd. This directly de-risks any roadmap item involving partner-sold inventory.
• Status visibility as a product lever: The new statuses parameter (pipe-separated, validated) lets PMs decide per-surface which reservation states are discoverable — e.g. show pending on a "complete your booking" page while keeping expired/cancelled hidden on public itinerary pages. Safe-by-default exclusions (pending, expired, cancelled) mean no accidental exposure without an explicit opt-in.
• Brand/UX consistency for error states: Tag failures now render the site's themed 404 instead of a bare Symfony error page. This removes a visible quality gap on high-traffic booking pages and reduces support tickets from customers hitting dead links.
• Operational diagnosability: Invalid parameters now throw clear, actionable messages, shortening the debug loop for engineering and reducing time-to-resolution on misconfigured tags.
• Build vs. buy: These are exactly the edge cases (partner bookings, status semantics, themed error handling) a team would otherwise rebuild in-house. Continued maintenance of this package strengthens the case for buy/adopt over custom reservation-resolution logic.

When to Consider This Package

Consider adoption when:

• You run a Laravel/PHP booking or reservation product with multiple sales channels, including affiliate or skip-payment partner flows that must resolve via URI.
• You need per-surface control over which reservation statuses are resolvable, and you want secure defaults rather than hand-rolled filtering.
• You care about brand-consistent error handling on customer-facing pages and want framework-native 404 behavior rather than raw exception pages.
• Your team values fast diagnosis of configuration mistakes via explicit validation messages.

Look elsewhere when:

• Your reservation model has no URI-based resolution pattern, or reservations are always fetched by authenticated session/ID.
• You need status values beyond the package's known set — the statuses parameter validates against a fixed list, so novel or custom statuses require upstream changes.
• You require fine-grained authorization per reservation (the tag resolves by URI, so access control must live in your application layer).
• You are unwilling to track a package whose correctness depends on your booking domain's evolving status and channel definitions.

How to Pitch It (Stakeholders)

To executives: v6.4.0 closes a revenue-adjacent gap — affiliate and partner bookings now resolve correctly on customer-facing pages instead of 404'ing, and failures degrade to our branded 404 rather than an ugly framework error. It also gives us a configurable, safe-by-default switch for which booking states are publicly discoverable. Net effect: fewer broken customer journeys, lower support load, and no custom build needed for channel-specific reservation lookup.

To engineering: This is a low-risk minor release — additive parameter, a correctness fix for partner/skip-payment bookings, and improved error surfaces (themed 404 plus validated, actionable parameter errors). Defaults remain conservative: pending, expired, and cancelled stay excluded unless explicitly requested. Adopt by wiring the statuses parameter only where a product decision requires it, and confirm the themed 404 template is registered in each environment. No breaking changes identified; upgrade and regression-test affiliate reservation pages.