- How do I install and configure misaf/laravel-sms-gateway?
- Install the core package with composer require misaf/laravel-sms-gateway, then install at least one driver package such as misaf/laravel-sms-gateway-ghasedak or misaf/laravel-sms-gateway-twilio. Publish the config file using php artisan vendor:publish --tag=sms-gateway-config. Set the default driver via the SMS_GATEWAY_DRIVER environment variable, and add the provider credentials to config/services.php using the driver's expected keys (for example an api_key entry). Check each driver package's README, since credential names differ per provider.
- Does this package support Laravel 10, 11, or 12?
- No. The README states a floor of PHP 8.3+ and Laravel 13+, which excludes Laravel 10, 11, and 12 applications as-is. Before committing, run composer why-not misaf/laravel-sms-gateway against your target app and inspect the illuminate/* constraints on both the core and driver packages. Relaxing those constraints means forking the package, which is a maintenance cost you should weigh before adopting it as a dependency.
- How do I switch SMS drivers per request at runtime?
- The package is built around Laravel's Manager pattern, so the driver is resolved from config by default but can be selected per request. You can call the manager's driver method with a configured driver name before sending, which lets you route OTP messages through one provider and marketing traffic through another. Keep the driver name in your own configuration or a routing class rather than scattering strings across the codebase. Because drivers are separate Composer packages, only drivers you have actually installed can be resolved.
- Which SMS providers are supported?
- First-party drivers exist for Ghasedak, IPPanel, Kavenegar, Magfa, Melipayamak, SMS.ir, Sunway, MessageBird, Plivo, TextLocal, Twilio, and Vonage. Most of the original driver set targets Iranian providers, so if you are routing to international numbers validate coverage, sender ID rules, and pricing with your chosen provider first. If a provider you need is missing, the custom driver registration hook is the intended extension point.
- How do I create a custom SMS driver for a provider that isn't covered?
- The package exposes a custom driver registration hook, so you can implement a driver class and map it to a driver name without forking the core. In practice you build a class that wraps the provider API using Laravel's HTTP client and returns the response payload the manager expects, then register it via the manager's extend method in a service provider. Registering it lets you keep the same facade, events, and per-request driver switching as the first-party drivers. Review an existing first-party driver's source to confirm the exact interface and expected return shape.
- How do I test SMS sending without hitting a real provider API?
- Drivers that use Laravel's HTTP client are testable with Http::fake(), which lets you assert the outgoing request URL, headers, and body and return a canned provider response. That covers the submission path, but confirm whether the driver you use goes through the HTTP client directly or wraps a vendor SDK. If you use a vendor SDK, you will need to mock that SDK yourself or abstract the driver behind your own contract so tests can swap in a fake.
- Does the package fire events after sending an SMS?
- Yes, sends emit an SMS sent event carrying the request and response payloads, so you can attach listeners for logging, metrics, or audit trails. Because those payloads include recipient numbers and message bodies, treat them as PII and redact before writing to shared logs or third-party observability tools. Confirm in the source whether the event fires on failures as well as successes, and whether it is dispatched before or after the HTTP response.
- Does it handle queueing, retries, rate limits, and 429 responses?
- The package is a thin driver manager, so queueing, exponential backoff, and throttling should live in your application rather than relying on the package. Route every send through a queued job from day one so retry and rate-limit policy remains under your control. Verify the failure semantics before going live: check whether a send throws an exception, returns a result object, or fires and forgets, and whether a retry can produce a duplicate message when the provider accepted the request but the response timed out.
- Does it support delivery receipts (DLR) or only submission acknowledgement?
- The documented surface is submission only: the driver sends a request and emits an event with the request and response data. Delivery receipts require an inbound webhook endpoint from the provider plus persistence of provider message IDs, and that is not described in the README. If you need DLR tracking, plan to build the webhook controller, the message status table, and the correlation logic yourself, and confirm whether the driver exposes the provider message ID in its response payload.
- Is misaf/laravel-sms-gateway safe to use in production?
- Treat it as a young, single-maintainer package: it has very low adoption, no evident dependents, and no published CI, static analysis, or security policy, so there is no external validation that it runs in production outside the author's own app. None of that makes it broken, but it does mean you carry the upgrade and support risk. If you adopt it, wrap it behind your own SmsSender contract or a Notification channel so replacing it later is an adapter swap, and pin versions deliberately after reviewing the tagged release history.