Clickatell Laravel Package

Product Decisions This Supports

• Whether SMS earns a place in the notification stack at all. This package makes the "yes" answer cheap to test on a Laravel product: register the channel on your notifiable models, add a toClickatell() method, and SMS becomes one more channel routed per-user alongside mail, database, and push. That reframes the real question from "can we do SMS?" to "which messages justify the per-message cost, the opt-in friction, and the compliance overhead?"

• Sequencing within SMS. Because the channel is queueable and reuses your existing notification classes, you can ship one high-value flow, measure it, and widen only if the numbers hold. The natural ladder: OTP/2FA and password reset first (highest value per message, lowest blast radius, failures are loud and immediate), transactional alerts second (order shipped, appointment reminder, payment failed), broadcast/marketing last (highest unit cost, highest consent exposure). Nothing in this package pushes you to launch all three at once — treat each as a separate product bet.

• Vendor selection, which is the decision that actually matters. Clickatell's commercial strength is carrier coverage and delivery quality in Africa and the Middle East, plus a long history in bulk/enterprise messaging. If your roadmap includes those markets, or you already hold a Clickatell contract, this driver is a near-zero-cost way to validate the channel. If your users are US/EU-only, Twilio, Vonage, or AWS SNS will likely offer better SDK support, delivery webhooks, and local compliance tooling — with better-maintained Laravel integrations.

• Build vs. buy, which honestly collapses to "build eventually." Read the description plainly: this is a thin driver that formats a request to Clickatell's messaging API and hands it to Laravel's pipeline. That's roughly one small class plus a config entry. The correct PM framing is adopt temporarily, replace deliberately — it buys you a day now, and should be budgeted as a known, small, scheduled replacement cost rather than treated as strategic infrastructure.

• Scope discipline on the vendor relationship. Clickatell also sells WhatsApp Business and broader messaging APIs. A package covering outbound SMS only should not be read internally as "we've integrated Clickatell." If WhatsApp notifications are on the roadmap, plan a separate integration; don't let this dependency create a false sense of coverage.

• Delivery observability, which this package explicitly does not provide. It handles outbound send only — no delivery receipts, no status webhooks, no callback parsing. If your product needs "did the OTP actually arrive?" (and for 2FA fallback logic, it does), that's additional engineering against Clickatell's API outside this package. Decide this before SMS lands on a critical path, because it materially changes the effort estimate, not just the polish.

• Sizing the surrounding work, so the estimate isn't a lie. The package is the smallest line item in an SMS launch. The real scope sits around it: consent capture and STOP/suppression handling (regulatory, non-negotiable), E.164 phone normalisation enforced at write time, sender-ID registration per destination country, outbound send logging for support, and queue/rate-limit tuning against your Clickatell plan's throughput. A PM who scopes this as "one composer require" will be surprised by a two-to-three-week delivery.

When to Consider This Package

Consider it when all of the following hold:

• You're on Laravel 8, or you've verified with composer why-not that it resolves cleanly against your actual lockfile. The last tagged release is 0.1.5 (September 2021) — pre-1.0, single maintainer, zero dependents, no community-tested compatibility matrix. On Laravel 10+ the honest options are pin-and-vendor it, or write the ~50-line channel yourself.
• You already have or want a Clickatell account, or your user base is concentrated in markets where Clickatell's coverage is the differentiator.
• Your first scope is outbound transactional SMS only — OTP, password reset, order/appointment alerts. No inbound keywords, no delivery-confirmation-driven logic.
• You're comfortable treating the driver as an implementation detail behind your own SmsSender seam, so a vendor swap later is a one-class change rather than an incident.

Look elsewhere when:

• You need delivery receipts or webhooks as a first-class capability — that's a build against Clickatell's status API regardless of which Laravel package you pick.
• You're US-focused, where alphanumeric sender IDs are rejected or overwritten and local compliance tooling matters more than carrier reach.
• You need a maintained dependency with a support path. Ten stars and a 2021 last release means you own the upgrade risk. If your team can't absorb that, pay for a vendor with a supported SDK.
• SMS is going on the auth path and you haven't yet decided who owns fallback logic (SMS → voice → email). Solve that design question before adding the dependency, not after.

How to Pitch It (Stakeholders)

For executives — one paragraph: SMS is a candidate channel, not a committed one, and this package lets us prove or kill it cheaply. It plugs Clickatell into the notification system we already run for email and in-app alerts, so we can ship a single high-value flow — most likely OTP or password reset — in days rather than weeks, and measure cost-per-message and completion before committing to broader rollout. The package itself is a small, MIT-licensed, community-maintained connector: low cost, low strategic weight, and something we should plan to own or replace within a year. The real investment isn't the package — it's consent handling, phone-number hygiene, sender-ID registration, and delivery logging, which we'd need with any vendor.

For engineering — the honest summary: It's a ~50-line channel that formats a request to Clickatell's messaging API and rides Laravel's notification pipeline. You get queueing, retries, and per-user channel routing for free; you get no delivery receipts, no inbound STOP handling, and no response-body validation beyond whatever send() chooses to inspect. Compatibility is unproven above Laravel 8, so verify against the lockfile before anyone writes code. Two non-negotiables: wrap it behind our own SmsSender interface so the vendor is swappable, and log every outbound send (recipient, body hash, response ID) via NotificationSent/NotificationFailed so support can answer "I never got the code" in minutes. Queue everything, rate-limit OTPs, keep message bodies ASCII to avoid silent UCS-2 segment doubling, and normalise phone numbers to E.164 at write time — not at send time, where failures disappear into a queue.

The ask: one engineer, roughly one sprint, to ship OTP-or-password-reset on a feature flag to a small cohort — with the SmsSender seam and send logging in place from day one. Review the dependency in six months or at the next Laravel major, whichever comes first.