- Can I use symfony/vonage-notifier in a Laravel application?
- Yes, mechanically you can install it with Composer in a Laravel app, but it is not a Laravel package. It provides a Symfony Notifier transport, not an Illuminate notification channel, service provider, config file, or facade. In Laravel you can only call it as a low-level library from a custom channel or domain service.
- How do I install and configure symfony/vonage-notifier?
- Install it with symfony/notifier using composer require symfony/notifier symfony/vonage-notifier. Configure a DSN in the form vonage://KEY:SECRET@default?from=FROM, where KEY and SECRET are your Vonage credentials and FROM is your sender. In practice you set VONAGE_DSN as an environment variable and pass it to VonageTransport.
- Does symfony/vonage-notifier integrate with Laravel notification channels?
- No. The bridge does not implement Illuminate\Notifications\Channel and does not register a Notification::extend driver. As a result it will not appear in a Laravel notification via() array out of the box. You must write a custom channel or service that wraps the Symfony Notifier transport.
- How do I send an SMS with symfony/vonage-notifier from Laravel?
- Create a Symfony Notifier instance with a VonageTransport built from your DSN, then send an SmsMessage through it. A typical pattern is (new Notifier([new VonageTransport($dsn)]))->send(new SmsMessage(...)) inside your custom Laravel channel class. That glue code is yours to own and test because the package does not provide it.
- Which PHP and Symfony versions does symfony/vonage-notifier support?
- Bridge versions track the Symfony release train. The v8 line requires PHP 8.4 or newer, so teams on PHP 8.1 through 8.3 must pin the 6.4 or 7.x line. That pin can constrain the Symfony packages resolved as transitive dependencies, so check it against your platform upgrade plans.
- Is symfony/vonage-notifier a good alternative to vonage/laravel-notification-channel?
- Not as a drop-in replacement. In a Laravel app the native Vonage notification channel plus the Vonage SDK is more idiomatic and requires no glue layer. The durable reason to choose this bridge is transport portability through symfony/notifier, such as SMS failover or swapping Vonage for Twilio or MessageBird later with a DSN and constructor change.
- Why does symfony/vonage-notifier show only 5 stars and 0 dependents?
- Those metrics describe a read-only subtree split of symfony/symfony, not a standalone project. Real adoption is invisible there because consumers depend on symfony/notifier and pull the bridge through the monorepo. Do not treat the low star and dependent counts as proof that the package is unused.
- Does symfony/vonage-notifier handle Vonage webhook callbacks and delivery receipts?
- No. The package does not include a controller, route, replay protection, or receipt logic; those are yours to build. It does provide signature-comparison hardening with hash_equals in patched releases, so if you accept callbacks use 6.4.39, 7.4.11, 8.0.11, or 8.1.0 and newer. If you do not accept webhooks, that security dependency is not relevant.
- Can I configure multiple sender numbers or per-tenant credentials with symfony/vonage-notifier?
- Configuration is DSN-only, so the from number and credentials are fixed per transport instance. There is no built-in per-tenant or per-message from-number support. To vary senders or tenants you must construct a second VonageTransport instance for each configuration.
- How should I test symfony/vonage-notifier without sending real SMS messages?
- The bridge does not ship Laravel-style fakes or dedicated testing helpers. You should mock Symfony's TransportInterface or inject a stub Notifier into your custom channel so no real HTTP calls reach Vonage. Because the integration glue is application code, test that glue layer directly rather than expecting the package to provide test doubles.