Laravel Iran Sms Laravel Package

Product Decisions This Supports

• Build vs. buy for SMS delivery in the Iranian market: This package wraps Ghasedak’s REST API for Laravel, so the decision is less “build vs. buy” and more “buy the gateway, buy the integration.” Release 1.4.2 removes the upstream ghasedak Composer SDK and implements the Ghasedak APIs directly inside the package. That means one fewer third-party dependency to audit, version-lock, or chase when the vendor changes its SDK — a meaningful supply-chain simplification for a component that sits in the critical path of OTPs, transactional notifications, and customer messaging.
• Feature decisions around user-facing messaging: If the product relies on SMS for 2FA/OTP, order confirmations, or marketing, this package gives the team a first-class Laravel abstraction (facade/config-driven) rather than hand-rolled Guzzle calls. That speeds up new notification flows and keeps delivery logic in one place.
• Roadmap risk: Because the package now owns the API implementation, its release cadence is tied to Ghasedak’s API rather than to the upstream SDK’s cadence. This is generally good for roadmap predictability but creates a maintenance ownership question — someone on engineering is now effectively maintaining a mini-SDK. That should factor into the “who owns this integration” conversation.
• Vendor concentration risk: Adopting this package hard-codes you into one Iranian SMS provider behind a package-specific interface. If there’s any roadmap possibility of a second provider (fallback, cost arbitrage, redundancy for deliverability), plan for an internal abstraction layer above this package rather than calling it directly from domain code.
• Use cases it cleanly supports: OTP/verification codes, transactional alerts (order shipped, payment received), and simple broadcast/marketing SMS — all routed through Laravel’s notification or service layer via config.

When to Consider This Package

Adopt when:

• You’re building on Laravel and need SMS in the Iranian market where Ghasedak is the chosen or standard gateway.
• You want a batteries-included integration (config file, facade, Laravel-native idioms) instead of writing and maintaining HTTP clients yourself.
• You value a dependency-light footprint — 1.4.2’s removal of the ghasedak Composer dependency is a genuine plus for security review and long-term maintenance.
• Your team is comfortable with a community-maintained package in the messaging path and has a plan for pinning versions and monitoring releases.

Look elsewhere when:

• You need multi-provider SMS routing, failover, or cost-based switching — this package is single-vendor by design.
• You require a vendor-neutral messaging abstraction (e.g., Laravel Notification channels that aren’t Ghasedak-specific), or you’re outside Iran and using Twilio/Vonage/SNS.
• You need guaranteed SLAs and commercial support — community packages like this typically have neither, and going direct to Ghasedak’s own SDK or API may be more defensible for an enterprise audit.
• Your security posture forbids pulling in a package that now reimplements a vendor API rather than using the vendor’s officially supported client — the trade-off in 1.4.2 cuts both ways.

How to Pitch It (Stakeholders)

To executives: This is a small, focused Laravel integration for Ghasedak SMS, the kind of plumbing that lets us ship OTP, transactional, and notification features without bespoke infrastructure work. The 1.4.2 release is a maintenance-quality improvement: it removes a third-party dependency and inlines the vendor APIs, which reduces our dependency surface and simplifies security review. It does not change the product surface area, but it does mean we should assign clear ownership of the integration and pin the version in composer.json. Recommended position: adopt for SMS features, keep usage behind a thin internal service so we retain optionality on providers.

To engineering: 1.4.2 is a low-risk, non-breaking release — no API changes for consumers, just the removal of the ghasedak Composer package and a direct reimplementation of Ghasedak’s endpoints. Upside: fewer transitive dependencies, fewer version conflicts, and no lag waiting on the upstream SDK. Downside: we now rely on this package’s authors to keep pace with Ghasedak API changes, so treat it as a maintained dependency — pin the version, watch releases, and cover the critical OTP path with an integration test that hits a sandbox or mock. If you’re abstracting notifications, wrap the facade behind an interface so a second provider can be swapped in without touching domain code.