- Is calisero/calisero-php a Laravel package?
- No. Despite often being filed alongside Laravel packages, it is a framework-agnostic PHP SDK for a third-party SMS gateway. It ships no service provider, facade, publishable config, or queue-aware transport. In a Laravel codebase it sits in the same slot as any HTTP client wrapper: a leaf dependency you call from a job or a notification channel. If you want Laravel-style configuration, write a small service provider of your own that binds the client.
- How do I install and configure calisero/calisero-php in a Laravel app?
- Install it with composer require calisero/calisero-php, then keep your API credentials out of source control. Put the key in config/services.php reading from an environment variable, and resolve the client through the container rather than instantiating it inline. The mechanical integration is one require, one config entry, and one call site. Budget hours, not sprints, for the wiring itself.
- Which PHP and Laravel versions does calisero/calisero-php support?
- Because the SDK is framework-agnostic it does not declare a Laravel version constraint at all, which is a feature rather than a gap. Check composer.json for the required PHP version and for any hard pin on guzzlehttp/guzzle or PSR-18 implementations. A tight Guzzle constraint is the most plausible source of a conflict with laravel/framework. Run composer why-not guzzlehttp/guzzle before committing to the dependency.
- How should I structure Calisero SMS sending inside a Laravel application?
- Define an SmsSender interface in your application layer and write a CaliseroSmsSender adapter that implements it, then bind the adapter in a service provider you own. Never let the vendor client type-hint leak into controllers, models, or domain services. Dispatch sends from a queued job with tries, backoff, and an idempotency or ShouldBeUnique key. This indirection costs very little and gives you a clean exit ramp if you change providers.
- Is calisero/calisero-php safe to use with queues and Laravel Octane?
- That depends on whether the client is stateless across requests, which you should verify in the source before enabling Octane. Look for mutable client state, cached responses, or direct reads of $_ENV and other globals. Under queue workers the same concern applies: a long-running process must not hold a stale client or a shared mutable payload. If in doubt, resolve the client per job rather than as a singleton.
- Does calisero/calisero-php retry failed requests automatically, and could that double-bill me?
- Retry behavior is not documented in the overview, so inspect the source for timeout, retry, and backoff defaults before going live. An SDK that silently retries 5xx responses can send the same SMS twice and bill you twice, which is the single most expensive failure mode for an SMS client. Set explicit timeouts and make your own job layer the only place retries are decided. Combined with an idempotency key, that keeps duplicate sends under your control.
- How do I test SMS sending without hitting the Calisero API?
- Test against your own SmsSender interface, not the vendor class. Bind a LogSmsSender or NullSmsSender implementation in your test service provider so local development and CI never touch the network or incur cost. If the SDK uses Guzzle underneath, a mock handler lets you assert request shape and exercise error paths. Keep one opt-in integration test that runs against a sandbox key for a real round trip.
- How do delivery receipts and inbound messages work with the Calisero SMS API?
- The overview does not state whether delivery receipts are pushed via webhook or pulled by polling, so confirm this with the vendor before designing around it. If they are pushed, route them to a dedicated controller that verifies the payload signature and is idempotent on replay, then queues any follow-up work. Do not assume webhooks are signed or replay-safe without checking. If receipts are pull-only, plan a scheduled job with sensible polling intervals.
- Is calisero/calisero-php production-ready and actively maintained?
- Ecosystem signal is very low: roughly one star, zero dependents, and no visible downstream projects to inspect for real-world usage. There is no publicly confirmed CI pipeline, static analysis, or test suite, which are the usual proxies for whether a patch release will break you. The license is permissive and the code is forkable, but the API behind it is not, so forking the client does not protect you from endpoint or rate-limit changes. Treat this as a provider decision and run a spike covering auth, a single send, and a receipt round trip before committing.
- What are the alternatives to calisero/calisero-php for sending SMS in Laravel?
- The realistic alternatives are another provider's SDK, a thin wrapper over Laravel's HTTP client, or a notification channel backed by your own adapter. Because SMS is a peripheral capability rather than a domain concern, the abstraction you build matters far more than the specific client you start with. Keep the SmsSender interface vendor-neutral and you can run two providers side by side during migration. That also hedges the vendor concentration risk of relying on a single small gateway.