- Is calisero/calisero-symfony a Laravel package?
- No. It is a Symfony bundle (namespace Calisero\SymfonySms) that ships a bundle class, services.yaml service wiring and a DependencyInjection configuration tree. Laravel has no bundle loader and does not consume Symfony's DI extension conventions, so the package cannot be auto-discovered or registered in a Laravel application. What is reusable in Laravel is the underlying Calisero PHP SDK, calisero/calisero-php, which the bundle only wraps.
- How do I install and register calisero/calisero-symfony?
- Require it with composer require calisero/calisero-symfony:^1.0.1, then enable the bundle in config/bundles.php and supply your API credentials through the bundle's configuration tree. Because it registers services through Symfony's container, it expects symfony/framework-bundle style conventions at runtime. Installation effort is low, but only inside a Symfony application.
- How do I integrate Calisero SMS into a Laravel application?
- Skip the bundle and require the SDK directly with composer require calisero/calisero-php. Add a config/calisero.php file for credentials, bind a configured client as a singleton in a ServiceProvider, optionally expose a Facade, and dispatch sends through a queued job so HTTP calls do not block requests. This is a small amount of glue code that stays entirely under your control, but you own it permanently.
- How should I configure Calisero API credentials securely?
- Keep credentials in environment variables and reference them from the package configuration rather than committing keys to version control. In Symfony that means the bundle's config file under config/packages reading from env vars; in Laravel it means config/calisero.php reading from env(). Also make sure config caching is refreshed after any credential change, since cached configuration will otherwise keep stale values.
- Does this package support Laravel 10 or Laravel 11?
- It does not declare Laravel support at all, because it is a Symfony bundle rather than a Laravel package with a service provider and auto-discovery entry. Framework compatibility for a Laravel app therefore depends on the PHP version constraints of the underlying SDK, not on this bundle. If you want a supported Laravel integration today, build it around calisero/calisero-php.
- Why does composer install fail after the rename from calisero/symfony-sms?
- The package was renamed to calisero/calisero-symfony in release 1.0.1, and the old name is no longer listed on Packagist, so any composer.lock, CI cache, internal mirror or Docker layer referencing calisero/symfony-sms will fail on a cold resolve. The PHP namespace is unchanged, which makes the break easy to miss locally on warm caches. Remove the old requirement, re-resolve from a clean cache, and rebuild CI images and mirrors.
- Does Calisero support idempotency keys, retries and delivery status callbacks?
- Those are SDK and API concerns rather than bundle concerns, so check the calisero/calisero-php documentation and the vendor's API reference before committing. Idempotency keys, retry and backoff behaviour, delivery receipts and per-message cost reporting are the capabilities that usually decide an SMS vendor. If any of them are missing, wrap the client behind your own interface so you can add retries and switch providers later.
- How do I test SMS sending without hitting the live API?
- Do not call the real gateway from your test suite. Define a small interface around the Calisero client, bind the real implementation in production and a fake or in-memory double in your test container so assertions run against recorded sends. If the SDK allows injecting an HTTP client, point it at a stub so you can assert request payloads, retry behaviour and error handling without spending money on messages.
- What are the alternatives to calisero/calisero-symfony for sending SMS in Laravel?
- For Calisero specifically, the practical alternative is the Calisero PHP SDK used directly with a small ServiceProvider binding. Beyond that, other SMS providers publish Laravel-specific packages with notification channel support, and a generic HTTP client integration works for any vendor with a REST API. If SMS is not core to your product, a maintained notification-channel package usually beats a hand-rolled integration.
- Who maintains this package, and what should I check before adopting it?
- The release history suggests a thin maintenance margin and effectively a single maintainer, with broken README, CI and support links shipped in 1.0.0 and a rename delivered as a patch in 1.0.1. Before adopting, confirm who owns the new Packagist vendor entry, that the repository URL resolves, and diff the 1.0.1 tree against 1.0.0 rather than treating it as a routine patch. Also agree on a fallback plan, such as your own interface over the SDK, in case the package or vendor disappears.