Laravel Whatsapp Laravel Package

Product Decisions This Supports

• Build vs. buy for WhatsApp channel: This package collapses what is typically a multi-sprint build (Cloud API client, webhook receiver with HMAC verification, media handling, message persistence, admin UI, retry semantics) into a composer require plus config. The decision shifts from "do we have 4–6 engineer-weeks for a messaging channel?" to "which backend(s) do we enable and when do we ship?"
• Backend strategy — dual-backend is the core product lever. The package lets you route transactional/template traffic through Meta Cloud API (official, scalable, no ban risk) while using the whatsapp-web.js sidecar for capabilities Cloud API structurally cannot provide: personal-number pairing, groups, status/stories, and free-form messages outside the 24-hour window. That is a genuine feature unlock for support/ops workflows (group-based coordination, personal-number outreach), not just an implementation detail — but it carries a ToS gray-area and ban risk that must be an explicit, owner-assigned product decision, not an engineering default.
• Roadmap sequencing: The roadmap tells you what you get now vs. later. Bulk send with rate limiting is not shipped — so any campaign/broadcast feature must be scoped as dependent on that work or built on top of the queue job yourself. Native Echo channel listeners and the template builder UI are likewise pending; assume template management is API/config-driven for now.
• Scope of the surface area you're adopting: Livewire + Flux admin UI at /whatsapp (dashboard, sessions/QR, compose, conversations with media/ack ticks/search, groups, contacts, webhook log, health), Eloquent models WaSession/WaMessage/WaContact, queued SendMessage job, broadcasting hooks, and CLI lifecycle. That's a whole internal ops console — useful for support teams, but it's also a second UI inside your app that you'll need to auth-wrap and maintain.
• Use cases it cleanly enables: order/shipping notifications via approved templates, two-way support conversations, group coordination for field ops, contact lookup, and an internal "send a WhatsApp to this customer" tool for CS. The one-line WhatsApp::send() auto-routing by recipient shape is a nice DX win that keeps call sites backend-agnostic — useful if you want to start on Cloud API and add the sidecar later without rewriting.
• Adoption-risk inputs for the decision: 242 stars, zero dependents, single 1.0.x line, first public release recently followed by fast patch releases (1.0.1 Windows fixes, 1.0.3 sidecar resilience fixes for WhatsApp Web minification breakage). The 1.0.3 changelog is the most product-relevant signal: the sidecar path will break when WhatsApp changes its internals, and you inherit that maintenance burden. Cloud API path is far more stable.

When to Consider This Package

Adopt when:

• You're on Laravel 11/12/13 and PHP 8.2+ (8.4+ on L13) and want WhatsApp in days, not sprints.
• You need both official template messaging and the unofficial personal-number/group capabilities — the dual-backend facade is the differentiator and no other Laravel package in this space offers it bundled with UI and persistence.
• An internal ops/support console for WhatsApp is genuinely useful and you're fine auth-wrapping /whatsapp/* with your own middleware.
• You can run Node + Chromium (~600 MB) and a long-lived whatsapp:web:listen process under Supervisor/systemd — one process per session.
• You accept the sidecar as best-effort: browser automation of a personal number, session-bound, not horizontally scalable, and subject to breakage on WhatsApp Web changes.

Look elsewhere / don't adopt when:

• Scale is the requirement. The sidecar does not scale to millions; Cloud API does, but if you're doing high-volume campaigns, the missing bulk-send-with-rate-limiting feature means you'd build it yourself. Consider a dedicated messaging provider (Twilio, 360dialog, Gupshup) with mature throughput and support SLAs.
• You need only official Cloud API messaging. This package's value is the dual backend; for a single-backend template sender, a lighter client or direct HTTP calls may be less surface area to own.
• Compliance/procurement sensitivity. The sidecar is a documented ToS gray area with ban risk. If WhatsApp is a customer-facing revenue channel where a number ban is unacceptable, restrict yourself to Cloud API only — and be explicit that the package's headline features (groups, status, free-form) then go unused.
• Team can't own Node/Chromium ops. No Node runtime, no appetite for a browser-automation daemon in production, no monitoring for a long-running SSE bridge — then the sidecar half is a liability.
• Dependency-risk tolerance is low. Zero dependents, single maintainer, young 1.0.x. For a tier-1 system, treat it as "adopt with a fork/escape hatch" or vendor-pin.

Adoption conditions to set upfront: strong WHATSAPP_WEB_TOKEN and WHATSAPP_APP_SECRET, UI route behind your auth middleware, sidecar bound to 127.0.0.1, whatsapp:health --exit-code wired into monitoring, and an explicit decision recorded on whether the sidecar is allowed at all.

How to Pitch It (Stakeholders)

To executives: "We can add a WhatsApp channel — the thing customers actually use — in days instead of a quarter. It gives us two modes: the official Meta API for compliant, scalable notifications, and a personal-number mode that unlocks groups and open conversations official APIs don't allow. It ships with an internal console so support can see and reply to messages without new tooling. Cost is low (MIT license, no vendor fees). The trade-off to decide on: the personal-number mode is unofficial and carries a ban risk and an ongoing maintenance tail, so it's opt-in per use case, not a default. Recommendation: enable Cloud API first for transactional messaging, pilot the sidecar for internal ops, and hold any bulk-campaign feature until rate-limited sending lands."

To engineering: "One composer require gives us a pure-PHP Cloud API client (templates, media, business profile, phone numbers, HMAC-verified webhooks), a bundled ~300-LOC whatsapp-web.js sidecar for personal-number/groups/status/free-form, and a single WhatsApp:: facade with send() auto-routing by recipient shape — so call sites stay backend-agnostic and we can start on Cloud API and add the sidecar without rewriting. We also get Eloquent models, a queued SendMessage job with sensible retry semantics (no retry on permanent Meta errors), broadcasting, a Livewire/Flux admin UI with three CSS install modes (including standalone, zero-build), and CLI lifecycle + whatsapp:health --json for monitoring. We need to budget production ops: Node + Chromium (~600 MB), sidecar under Supervisor, one whatsapp:web:listen per session, UI behind our auth middleware. Known gaps to plan around: bulk send with rate limiting, native Echo listeners, template-builder UI. Risk note: 1.0.3 was a resilience fix for WhatsApp Web minifying its internals — expect the sidecar to need periodic attention, so keep the facade abstraction clean and Cloud API as the stable default."