Kudisms Notification Laravel Package

Getting Started

• Install the 2.x package:

  composer require toneflix/kudisms-notification:^2.0
  

• Upgrading from 1.x: remove the old package first, then require the new one:

  composer remove toneflix-code/kudisms-notification
  composer require toneflix/kudisms-notification:^2.0
  

• Publish the config file using the tag documented in the README (likely kudisms-config or similar), then set the KudiSMS credentials and sender ID in .env.
• Confirm you are on PHP 8.3/8.4 and Laravel 12/13 — 2.0 does not support older stacks.
• First use case: send an OTP or transactional SMS through Laravel’s notification system.

  use Illuminate\Notifications\Notification;
  use Toneflix\KudiSmsNotification\KudiSmsChannel;
  use Toneflix\KudiSmsNotification\KudiSmsMessage;
  
  class SendOtp extends Notification
  {
      public function __construct(public string $otp) {}
  
      public function via($notifiable): array
      {
          return [KudiSmsChannel::class];
      }
  
      public function toKudiSms($notifiable) // confirm exact method name in README
      {
          return KudiSmsMessage::create()
              ->to($notifiable->phone)
              ->content("Your OTP is {$this->otp}");
      }
  }
  
  $user->notify(new SendOtp('123456'));
  

• Look first at the README and the published config file. They define the exact message builder API, env keys, and whether per-message sender IDs are supported.

Implementation Patterns

• Use Laravel notifications as the primary integration. The package provides a notification channel; return its channel class from via() and build the SMS in the channel-specific method.
• The message builder is the main day-to-day API: create a message, set the recipient phone number, set content, and optionally override the sender ID if the package supports it.
• Queue notifications by implementing ShouldQueue on your notification class. The channel will then run inside your queue worker, which is important for SMS latency and retry handling.
• For one-off sends outside the notification system, resolve the package’s channel or client from the container. Check the service provider for bindings or a facade before reaching for raw HTTP calls.
• Testing pattern:
  • Use Notification::fake() and assert the notification was sent to the right notifiable on the KudiSMS channel.
  • For channel-level tests, fake outgoing HTTP with Http::fake() if the package uses Laravel’s HTTP client, then assert the request payload.
• Multi-tenant or per-tenant credentials: set config values at runtime before sending, or use per-message sender overrides if available. Avoid hard-coding credentials in notification classes.
• Keep phone normalization in one place (e.g., a cast, mutator, or helper). KudiSMS expects a specific MSISDN format; normalize to international format before the channel sees it.
• If the package exposes a message class, extend or wrap it in your own builder when you need consistent branding, sender IDs, or content templates across many notifications.

Gotchas and Tips

• 2.0 is a breaking rename: the package moved from toneflix-code/kudisms-notification to toneflix/kudisms-notification, and the namespace changed from ToneflixCode\KudiSmsNotification to Toneflix\KudiSmsNotification. Update every use statement and any published config references.
• Remove the old package before installing the new one to avoid duplicate classes or autoload conflicts.
• The new requirements are strict: PHP ^8.3|^8.4 and Illuminate ^12.0|^13.0. If your app is on Laravel 10/11 or PHP 8.2, stay on 1.x until you upgrade.
• After publishing or editing config, clear cached config:

  php artisan config:clear
  

  In production, re-run php artisan config:cache.
• Confirm the exact notification method name the channel expects (commonly toKudiSms, but verify in the README). If the method is missing or misnamed, Laravel may silently skip the channel.
• Watch phone number formatting. A malformed number often surfaces as a provider-side error rather than a Laravel exception, so validate and normalize before sending.
• Handle API failures deliberately. Decide whether SMS failures should fail the whole notification, be logged, or be retried by the queue. Use queue backoff and retryUntil where appropriate.
• Notification::fake() does not exercise the real channel. Use HTTP fakes or a package-level fake if provided to test payloads and error paths.
• Check the service provider for extension points: config overrides, custom HTTP client bindings, base URL changes, or a replaceable message class. Those are the safest places to customize without forking.
• SMS providers rate-limit. Queue and throttle high-volume sends rather than firing them synchronously in a request.