Laravel Sms Gateway Kavenegar Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging delivery. This is a thin driver that plugs Kavenegar's SMS API into the laravel-sms-gateway abstraction. Adopting it removes the need to hand-roll HTTP client code, retry/error handling, and payload shapes for one provider — a few days of engineering you don't spend on a non-differentiating capability.
• Provider selection for the Iranian market. Kavenegar is one of the dominant local SMS providers for Iran. This package is a low-friction way to add it to a Laravel stack and defer a full messaging-platform decision (Twilio/Infobip/etc.) until volume or reach justifies it.
• Feature roadmap inputs: OTP/login verification, transactional notifications (order updates, receipts, alerts), and one-off sends are all in scope. The package covers the delivery layer only; templates, rate limiting, opt-out/compliance, and delivery analytics remain product work you own.
• Multi-provider / failover strategy. Because it implements a shared gateway interface rather than binding your code to Kavenegar's SDK directly, it keeps the door open to a second provider (non-Iran numbers, failover, cost routing) with minimal rework.
• Cost-of-ownership signal. A major version bump (v1.0.0 → v2.0.0) is evidence of an actively versioned dependency — but also of churn. That shapes whether you pin tightly or treat the package as a maintained commodity.

When to Consider This Package

Adopt when:

• Your app is Laravel/PHP and you already use, or are willing to adopt, the laravel-sms-gateway abstraction.
• Kavenegar is your SMS provider for Iran, or one of a set you route to.
• Your needs are standard: send a templated message to a number, interpret the provider response, surface failures. A thin adapter is the right amount of dependency for that job.
• You want to avoid maintaining bespoke API glue and can live with an upstream maintainer's release cadence.

Look elsewhere when:

• You need providers outside Kavenegar's coverage (global reach, US/EU compliance, WhatsApp/RCS).
• You need campaign management, segmentation, deliverability dashboards, or A/B testing — this is plumbing, not a messaging platform.
• You are not on Laravel, or you already standardize on a vendor SDK / a broader abstraction you don't want to fragment.
• You cannot absorb a breaking change right now — see the release note below.

Release-specific note (v2.0.0): the published notes are a changelog link only, so the concrete changes are unverified at assessment time. Treat this as a re-evaluation trigger: pin to a known-good version, diff v1.0.0 → v2.0.0 in a short spike, and confirm compatibility with your Laravel/PHP versions and the parent gateway package's major version before rollout. A v2 major bump should be assumed breaking until the diff says otherwise.

How to Pitch It (Stakeholders)

For executives: This is a small, cheap integration that gets us SMS delivery to Iranian users on a mainstream local provider without a custom build. It underpins table-stakes features — OTP login and transactional messaging — for roughly a few engineering days rather than an owned, hand-maintained integration. The main risk is a single-provider dependency; the shared gateway interface largely mitigates it, since a second provider can be added later without re-architecting. Recommend a time-boxed review of the v2.0.0 changes, then pin and proceed.

For engineering: It's a driver, not a framework. It implements laravel-sms-gateway's interface against Kavenegar, so it stays small and swappable. Trade-offs: coupling to the upstream abstraction's release cycle and to maintainer responsiveness. The v2.0.0 major bump should be treated as a breaking change until the changelog proves otherwise — budget a short spike, pin the version, and confirm it matches our Laravel/PHP baseline and the gateway package's expected major before rollout.