Chat Api Laravel Package

Product Decisions This Supports

• Channel strategy / roadmap sequencing: Whether WhatsApp is a first-class support or notification channel. This package is the canonical example of the "unofficial path" — it proves the capability is technically reachable but not productizable. Use it to force the roadmap question: build on the official WhatsApp Business Platform (Cloud API via Meta or a BSP such as Twilio, 360dialog, Gupshup, Infobip) or defer the channel and invest in SMS/RCS/email/in-app first.
• Build vs. buy: Strong evidence for buy. This library shifts an unbounded reverse-engineering burden onto your team: protocol drift, Signal-protocol end-to-end encryption, multi-device support, and registration flows that upstream can disable at will. Any "we could just build it ourselves" proposal should be measured against this package's trajectory — high initial traction, zero sustainable maintenance — and against BSP pricing.
• Product constraints that shape UX: Choosing the official route imports real product rules — opt-in capture, template message approval and review latency, the 24-hour customer service window, per-conversation pricing, business verification. These are UX and lifecycle decisions (onboarding flows, consent capture, message-template design tools, fallback-to-SMS logic) that need to be scoped before a WhatsApp feature is committed, not after.
• Risk register and compliance posture: Account bans of the business number, Meta Terms of Service violations, historical takedown/DMCA exposure, absence of a data processing agreement, and GDPR/CCPA handling of end-user phone numbers and message content through an unofficial client. This is a "do not do" entry that product should own explicitly rather than leave to an individual engineer's initiative.
• Tech-debt and migration triage: If any legacy service already depends on this package, quantify exposure — which flows break if the number is banned tomorrow, and what the migration cost to the Cloud API looks like (auth, templating, webhook handling, media).
• Supply-chain and dependency policy: Zero dependents, unmaintained, no security response process. A useful worked example for a "no unmaintained single-maintainer dependencies in customer-facing paths" rule in your engineering standards.

When to Consider This Package

Legitimate, narrow uses:

• Protocol archaeology and competitive research — reading the source to understand how WhatsApp Web historically authenticated and transported messages.
• A throwaway internal lab prototype on a disposable number, with no real customer data, no production credentials, and an explicit decision date to delete it.
• Teaching material on reverse-engineered protocol clients and why they fail.

Do not adopt when any of the following is true — which covers essentially all product work:

• The feature touches real customers, real phone numbers, or real message content.
• You need reliability targets, an on-call path, security patching, or any form of vendor accountability.
• You need scale beyond a hobby volume, media handling, template messages, or delivery receipts.
• You operate in a regulated or enterprise-sales context where a DPA and lawful-basis story are required.
• You are on a supported PHP runtime and expect modern dependency hygiene.

Look elsewhere if you need the capability for real:

• Official: WhatsApp Business Cloud API (Meta-hosted, free-tier messaging, pay-per-conversation), or the on-premises API where still contracted; BSPs (Twilio, 360dialog, Gupshup, Infobip, Vonage) if you want abstraction, sandbox tooling, and multi-channel in one integration.
• Multi-channel abstraction: Twilio/Vonage/Infobip Conversations, Courier, Novu — buy the channel portfolio rather than each channel.
• Open-source bridging (still unofficial, but maintained and transparent about risk): Matrix bridges such as mautrix-whatsapp — acceptable only for internal/personal tooling with eyes open, never as the backbone of a customer-facing product.
• If the real need is "reach users on messaging apps": RCS, SMS with rich fallback, or in-app push usually deliver most of the value without the ToS and ban exposure.

The adoption signals here are decisive on their own: no stars displayed, zero dependents, score 0, unmaintained upstream, and a history of availability problems. Treat it as a reference implementation, not a dependency.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated whatsapp/chat-api, the best-known PHP library for talking to WhatsApp. It works by impersonating the WhatsApp client and speaking Meta's private, reverse-engineered protocol — which Meta prohibits and has actively disrupted. It is unmaintained, has no security response process, no dependents, and no vendor behind it. Adopting it would put our business number at risk of a ban that could take our messaging channel offline overnight, expose us to ToS and data-protection claims with no DPA, and leave us with a capability we cannot support. Recommendation: do not build on it. If WhatsApp is on the roadmap, we go through the official WhatsApp Business Platform via a BSP, and we budget for template approval workflows, opt-in capture, the 24-hour service window, and per-conversation pricing. That is a product and process cost — but it is bounded, whereas the unofficial path is not.

For engineering: No SLA, no release cadence, no CVE process, no test guarantees, and a protocol surface that changes without notice. The registration/authentication mechanism this library relies on has been broken by upstream changes, so even a "just prototype it" path has poor odds of staying alive for the length of a sprint. Estimated cost of ownership is a permanent on-call liability concentrated in one person; cost of exit is a rewrite of auth, webhooks, media handling, and template logic. If we have existing code on it, treat it as a P1 migration item.

For finance/procurement: The apparent savings are illusory. BSP fees and per-conversation pricing are a known, contract-backed line item; the unofficial route substitutes an unknown risk of channel loss, incident response, legal review, and re-platforming — plus the revenue attached to any customer journey that depended on the channel. A four-week spike against the official Cloud API sandbox is the cheaper way to learn whether WhatsApp is worth it.

The ask: Approve a short, scoped evaluation of the official WhatsApp Business Platform (or one BSP) against our top two messaging use cases, and formally retire whatsapp/chat-api from consideration — including a migration note if any internal tooling still references it.