Agendize Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on scheduling/booking infrastructure. This package is a thin Laravel client for Agendize (appointment booking, queue/ticketing, click-to-call). Adopting it is a commitment to Agendize as the scheduling system of record rather than building availability logic, calendar sync, timezone handling, and reminder delivery in-house — a decision worth modelling against 6–12 months of engineering cost.
• Roadmap sequencing for customer-facing booking. Enables a self-serve booking flow, staff-side calendar management, and reminder/notification features to be scoped as integration work rather than net-new product construction. Fastest path to a shippable "book an appointment" slice.
• Multi-channel service design. Agendize covers in-person, phone, and video appointment modes, which supports decisions about whether to offer queue management or click-to-call as differentiators or to defer them.
• Auth model and secrets handling. v0.1.6 adds apiKey + token credential support against the Agendize v2 API. This confirms the integration can be configured per-tenant via Laravel config/env, which matters for any B2B or multi-location roadmap where each client has their own Agendize account.
• Vendor lock-in risk register. A v0.1.x, single-maintainer-style wrapper around a proprietary SaaS means the integration layer is cheap to swap but the workflow/data model is not. That trade-off should be an explicit line in the platform risk log, not a silent default.

When to Consider This Package

Adopt it when:

• Agendize is already the chosen or shortlisted scheduling vendor, and Laravel is the application framework — this avoids hand-rolling HTTP client, auth, and DTOs.
• You need a scheduling integration shipped in weeks, not quarters, and the booking flow is supporting infrastructure rather than the core product.
• You require per-tenant credentials (apiKey/token), which v0.1.6 now exposes.
• Your team is comfortable pinning a pre-1.0 dependency and reading the vendor's REST docs directly, because the wrapper will not abstract everything.

Look elsewhere when:

• The package is pre-1.0. Expect breaking changes across minor versions; no stability contract. If your release cadence cannot absorb that, wrap it behind your own internal interface from day one.
• Scheduling is a core differentiator. A thin vendor wrapper gives you Agendize's model, not yours — custom availability rules, pricing, or resource logic will fight the API.
• You need offline/self-hosted scheduling, or data residency rules that prohibit a third-party SaaS holding appointment and customer PII.
• Agendize is not yet contracted. Do not let a convenient package become the reason a vendor gets selected; run the vendor evaluation first, then adopt the wrapper.
• You need deep framework integration (Eloquent models, migrations, events, Nova/Filament resources). Coverage here is likely HTTP-level only; budget internal work for persistence, sync, and idempotency.

On this release specifically: v0.1.6 is an incremental auth improvement, not a capability change. It removes a blocker for multi-tenant configuration but does not alter the adoption calculus. Treat it as evidence the package is maintained, not as a maturity signal.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost integration library that lets us plug a commercial appointment-scheduling service into our Laravel platform instead of building booking, calendar, and reminder infrastructure ourselves. The realistic comparison is a few weeks of integration work against several months of engineering plus ongoing maintenance. The trade-off is dependency on a third-party vendor for a customer-facing workflow, and the library itself is early-stage (v0.1.x), so we should isolate it behind an internal interface to keep switching costs low. Recommend a time-boxed spike, not a platform commitment.

To engineering: Thin Laravel wrapper over the Agendize v2 REST API. Latest release adds apiKey/token authentication, so per-tenant credentials are now viable. It is pre-1.0 — pin the version, expect breaking changes, and do not let it leak into domain code. Wrap it in our own adapter, own the persistence and idempotency layer ourselves, and treat the vendor docs as the primary reference. Estimate the spike as integration plus a contract test suite against a sandbox account.

Decision requested: Approval for a short evaluation spike (one engineer, ~1–2 weeks) to validate Agendize fit and the wrapper's coverage before any roadmap commitment.