Smsir Php Laravel Package

Product Decisions This Supports

• Channel strategy for Iran-facing products. This package is a thin PHP/Laravel client for the SMS.ir gateway, so it directly informs whether SMS — and specifically OTP/verification — becomes a supported notification channel in the product.
• Build vs. buy for messaging plumbing. It answers "do we write our own SMS.ir HTTP client, or adopt an existing wrapper?" A working wrapper converts a multi-day integration into an afternoon, which is a real input to sprint planning and launch sequencing.
• Roadmap enablement. Concrete features it unblocks: phone-number verification at signup, 2FA/login OTP, transactional alerts (order status, payment confirmation, appointment reminders), and bulk/marketing sends where the provider supports them.
• Vendor and lock-in posture. Because it is provider-specific (SMS.ir), adopting it is implicitly a decision to standardize on that gateway — or a forcing function to put an abstraction (Laravel notification channel or an internal SmsSender interface) in front of it before the first line of integration code ships.
• Market-entry gating. For teams evaluating an Iranian launch, this is a cheap way to de-risk the local messaging requirement without committing to a broader regional infrastructure investment.
• Effort and cost estimation. It gives a realistic baseline for "how much engineering does adding SMS cost?" — useful when comparing against aggregator platforms or CPaaS vendors that bundle analytics, routing, and dashboards.

When to Consider This Package

Consider it when:

• SMS.ir is already your provider, or is the incumbent your ops/BD team has contracted with.
• The stack is Laravel/PHP and you want idiomatic integration (service provider, config, facade) with minimal glue code.
• Your needs are simple and transactional: OTP/verification codes, single-recipient sends, templated messages.
• You are validating an Iran-market product and want the smallest possible commitment.
• You plan to wrap it behind an internal interface anyway, so its small surface area is an advantage rather than a limitation.

Look elsewhere when:

• Multi-provider routing, failover, or cost optimization is a requirement — you need a channel abstraction (or a CPaaS/aggregator), not a single-gateway client.
• You need delivery receipts, webhooks, campaign management, or analytics. Verify against the official SMS.ir API/SDK first; a community wrapper usually stops at "send."
• Your market isn't Iran or your provider isn't SMS.ir. The package is not a general SMS abstraction and offers no value as one.
• Maintenance risk is unacceptable. Signals here are thin: 16 stars, zero dependents, last release October 2024, and a single-company origin. That is fine for a vendored utility, disqualifying as a load-bearing dependency without a fork-and-own plan.
• Compliance, audit, or sender-ID/regulatory registration must be handled in-product — confirm the wrapper exposes what your legal/ops team needs, or plan to call the raw API.
• High-volume or latency-sensitive paths where you'd want connection pooling, queuing, retries, and backoff — check whether the package provides these or whether you must build them around it.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost integration that lets us test SMS and OTP in the Iranian market quickly. It is tactical, not strategic — a narrow client for one local gateway with a very small community and a single maintainer, so we should treat it as a replaceable component behind our own interface rather than a platform commitment. The decision it buys us is speed to a validated launch, not long-term infrastructure.

To engineering: It's a thin Laravel-friendly wrapper around the SMS.ir API — expect send and verification-code calls, not a messaging platform. Recommended posture: adopt it, but contain it. Define an internal SmsSender contract (or a Laravel notification channel) on day one, keep the provider behind config, and add our own retry/queue/logging layer rather than relying on the package for reliability. Before committing, verify test coverage, PHP/Laravel version support, and whether delivery-status callbacks are exposed. Budget a small fork-and-own contingency given the low release cadence and near-zero downstream usage.