Sms.to Laravel Lumen Laravel Package

Getting Started

This package is a thin Laravel/Lumen bridge to the sms.to transactional SMS API. There's not much surface area — expect a service provider, a config file with credentials, and a small sender API. Treat it as plumbing, not a framework feature.

1. Install (Laravel 10 is supported as of 1.2.0, so composer require intergo/sms.to-laravel-lumen resolves on a modern stack):

   composer require intergo/sms.to-laravel-lumen
   

   The release notes for 1.2.0 mention only Laravel 10 support, so verify the illuminate/* constraint actually widened rather than assuming — check composer.json in the tagged release before upgrading a project pinned to older Laravel.

2. Publish and configure. Look for the package's config file and .env keys immediately after install:

   php artisan vendor:publish --provider="Intergo\SmsTo\SmsToServiceProvider"
   

   You'll be filling in an API key/token and a default sender ID. Neither is optional — the API will fail at request time, not at boot time, so a misconfigured install looks healthy until you send.

3. Check the README for the entry point. The public API is small; read the provider's register()/boot() and the class it binds before writing anything. That's faster than guessing at facade names.

4. First use case: send yourself a single message from php artisan tinker with the facade or injected client, before you wire it into any flow. This isolates credential problems from application bugs.

If you're on Lumen, vendor:publish doesn't exist — copy the config file into config/ manually and register the provider plus $app->withFacades() in bootstrap/app.php.

Implementation Patterns

Wrap it, don't sprinkle it. The package's API is narrow and provider-specific. Define your own interface (SmsSender with a send(string $to, string $message) method), implement it with this package, and depend on your interface everywhere else. This is the single most valuable thing you can do, because it makes swapping providers a one-class change and makes testing trivial:

final class SmsToSender implements SmsSender
{
    public function __construct(private SmsToClient $client) {}

    public function send(string $to, string $message): void
    {
        $this->client->send($to, $message);
    }
}

Send from queued jobs or notifications, not controllers. SMS calls are network I/O to a third party. A notification channel fits well:

public function toSms($notifiable)
{
    return SmsMessage::to($notifiable->phone)->content('Your code: '.$this->code);
}

Then $user->notify(new OtpNotification($code)) and let the queue handle latency and retries. The package itself is not a queue integration — you supply that.

Multi-tenant / per-brand sender IDs. If different products send under different names, don't hardcode the config value. Either create a named client instance per brand or pass the sender ID per call if the API allows it, and keep the mapping in your own config rather than the package's.

Audit logging. Write a row (or log entry) for every outbound message: recipient, provider message ID, timestamp, and the raw response. When a customer says "I never got it," this is what you'll actually debug against — the provider dashboard alone rarely tells the whole story.

Integrate with your own retry/backoff. Queue retries plus a failed() hook that alerts is the pattern that survives production. Don't rely on the package for resilience.

Gotchas and Tips

• It's a wrapper, not a workflow engine. No templating, no scheduling, no delivery-report handling. Budget for building those yourself or accepting that you won't have them.
• Laravel 10 support ≠ PHP 8.0 support. Laravel 10 requires PHP 8.1+. If the 1.2.0 bump also raised the PHP constraint, your CI image needs updating too — a failed composer update here is usually a PHP version problem, not a package bug.
• Credential errors surface late and generically. A wrong API key typically produces an HTTP 401/403 with an opaque body. Log the raw response body and status at debug level for the first week after go-live; it will save you an afternoon.
• Lumen installs need manual config. No vendor:publish. Copy the config file yourself and confirm the merged key matches what the package reads — a typo'd config key silently falls back to null and produces a confusing runtime failure.
• Pin your version. The jump from 1.1.0 to 1.2.0 is a minor bump adding framework compatibility, but thin packages often carry subtle constraint changes in the same release. Use "intergo/sms.to-laravel-lumen": "^1.2" and let the lock file do its job.
• Testing: bind a fake implementation of your SmsSender interface in the container during tests. Never let the test suite touch the real API — you'll burn credits and produce flaky CI. If you must test the package layer, use Http::fake().
• Extension point: if you need headers, timeouts, or a custom Guzzle client, check whether the provider binds a client you can override with $app->bind(...) after registration. That's usually cleaner than forking.
• Rate limits are the provider's, not the package's. Batch sends will need throttling on your side (Bus::batch with a rate limiter, or redis throttle middleware on the job). This is the most common cause of "it worked in dev, failed in production" with SMS packages.