Kavenegar Laravel Package

Product Decisions This Supports

• Whether SMS/OTP ships at all. If the roadmap includes phone-based login, password reset, or 2FA for Iran-market users, Kavenegar is a mainstream local gateway and belongs on the vendor shortlist. This package is one (weak) implementation option for that channel — not the decision itself.
• Channel strategy for transactional messaging. Order confirmations, appointment reminders, account alerts — decides whether SMS is a first-class channel alongside email/push or a fallback for undeliverable email, and how much engineering to invest in a proper notification pipeline.
• Build vs. buy on the gateway adapter. The real decision is not this repo; it's whether to wrap Kavenegar's REST API ourselves (~2–5 engineering days including retries, rate limiting, dedupe, and logging) or adopt an SDK. This package is evidence against "buy": it's a thin, unmaintained adapter with no adoption signal.
• Framework upgrade sequencing. Adopting it pins the integration to Laravel 5.x conventions (and Laravel 4-era assumptions). If a move to Laravel 10/11 or PHP 8+ is anywhere on the roadmap, this dependency is a blocker, not an enabler.
• Vendor and compliance risk. Kavenegar is an Iranian provider; for any organization with US/EU nexus there are sanctions-screening, data-residency, and payment-channel questions. That's a decision to surface early, not a detail for engineering to absorb. This package's existence doesn't resolve any of it.
• Delivery-reliability expectations. Kavenegar returns HTTP 200 with error codes in the body, and this wrapper likely swallows them. That means "did the OTP send?" is a product question you cannot currently answer — a reason to own the adapter that interprets the response.

When to Consider This Package

Consider it only in one narrow case: you already operate a legacy Laravel 4.x/5.x application on PHP 5.6–7.x, you need Kavenegar wired up quickly for a fix or small feature, and the migration is already funded. Even then, treat it as a stopgap with an owner and a removal date, wrapped behind an internal SmsSender interface so it can be swapped out.

Do not consider it if any of the following hold:

• Target is Laravel 6+ or PHP 8+. Laravel 4/5 provider/facade conventions and old illuminate/support constraints won't line up cleanly; you'll need workarounds you'll regret.
• You need more than "send a text": queued notifications, a Notification channel, inbound-SMS webhooks, delivery-status callbacks, lookup/template APIs, idempotency, or retry/backoff policy. None of this should be assumed.
• Security or supply-chain review applies. Zero stars, zero dependents, score 0, no visible release cadence, no test/CI evidence — there is no maintainer to page for a CVE.
• You want production precedent. Zero dependents means effectively no one to learn from; you'd be the first adopter debugging it in production, including the silent-failure behavior above.

Look elsewhere or build instead:

• Write a small internal client (~40–100 lines) against Kavenegar's documented REST endpoints using Laravel's Http client, and expose it as a Notification channel. You own the upgrade path, the error semantics, and the logging.
• Or adopt the official kavenegar/laravel package / Kavenegar's own SDK if it is maintained and supports your framework version — check Packagist and the repo's last commit before writing anything.
• In either case, keep a SmsSender interface and fake it in tests so CI never burns credit or depends on the network.

How to Pitch It (Stakeholders)

For executives: This is an unmaintained community wrapper for an Iranian SMS gateway, written for the Laravel 4/5 era. Don't adopt it. The underlying question is still a real product decision — do we ship SMS/OTP for our Iran-facing users, and with which vendor? That needs compliance and vendor checks (sanctions exposure, data residency, payment channel) before we spend engineering time, because provider choice is much cheaper to resolve now than after launch. On the engineering side, the delta between this package and a small in-house client is roughly two days saved versus inheriting a dead dependency that blocks our next Laravel upgrade.

For engineering: Thin adapter over Kavenegar's REST API — facade + config + service provider, no maintenance signal (score 0, zero stars, zero dependents). Framework target is EOL. Integration cost is under a week either way, so the recommendation is to skip the dependency and spike a one-day internal client: Http-based send, a Notification channel, queued sending with rate limiting, structured logging of the raw response (remember Kavenegar returns 200 with errors in the body), and a FakeSmsSender for tests. Evaluate the vendor separately on compliance, pricing, and delivery reliability.