Client Laravel Package

Technical Evaluation

Architecture fit. Unchanged in substance. nexmo/client is still a Composer metapackage — it ships no source, no service provider, no config beyond what nexmo/client-core provides, and its only job is to pick a PSR-18 HTTP client for you so the client-core virtual-package dependency resolves. The 2.4.0 release does not alter that shape; it changes which client gets picked (Guzzle 7 instead of Guzzle 6). Architecturally this remains near-zero value and non-zero risk, because the pin is still implicit and still ours to inherit. The one improvement: Guzzle 7 implements PSR-18 natively, so the resolved stack is at least a modern, standard-conformant HTTP client rather than a pre-PSR-18 one.

Integration feasibility. Still mechanically trivial — one composer require, credentials, new \Nexmo\Client(...). The PHP floor moving to 7.2 and Guzzle to 7.0 does not change install effort on a modern stack; if anything it improves the odds that resolution succeeds cleanly, since Guzzle 7 is what most current Laravel applications already carry transitively. The post-install friction is unchanged: the package is still frozen at a 2020-era API surface and still superseded by Vonage.

Technical risk. Downgraded from High to Medium-High. The release materially retires two of the three previous concerns, but not the third.

• Lifecycle — partially mitigated, not resolved. This is the first release since 2020-09-10, and it is a dependency-hygiene release, not a feature or security release. It removes the most likely composer audit noise (Guzzle 6-era transitive CVEs) and the most obvious PHP floor problem. It does not establish a maintenance cadence. One commit after a multi-year gap is a drive-by, not a revival; we should not plan on a second. The package remains an abandoned transitional artifact with no security-response commitment, and the 2.4.0 bump tells us nothing about whether PHP 8.1/8.2 is actually tested or merely permitted by the constraint.
• Vendor drift — unchanged. Nexmo → Vonage rebrand, vonage/client / vonage/client-core as the maintained successors, retired and deprecation-clocked endpoints. Nothing in 2.4.0 addresses this, and it is now the dominant risk in the package. Any capability we build here is still code we know we must rewrite.
• Dependency coupling — improved but re-shaped. Guzzle 7 is a better citizen than Guzzle 6: PSR-18-conformant, PHP 7.2+, actively patched. But the metapackage still pins Guzzle, and the major-version jump is itself a coupling event — applications pinned to Guzzle 6, or to another PSR-18 implementation, will now conflict in the opposite direction. We have traded a stale pin for a fresher pin that will age again, with no mechanism to move it except another drive-by release we cannot count on.
• New: silent-upgrade hazard. A minor-version release (2.4.0) that raises the PHP floor and bumps a dependency major is a semver surprise. A routine composer update on an existing install can now pull Guzzle 7 and break co-installed packages, or fail outright on a PHP 7.0/7.1 host. This is a real, near-term operational event for anything already depending on the package.

Key questions. Which APIs do we actually need — SMS, Verify/2FA, Voice, Numbers, Messages? What PHP and Laravel versions must we support — and specifically, does 2.4.0's CI actually cover PHP 8.1/8.2, or is 7.2 just the declared minimum? Is any code in the estate already importing Nexmo\ namespaces, and is it pinned to Guzzle 6 today? Are we already on an HTTP client we cannot move off? Is any code in the estate already importing Nexmo\ namespaces? Do we have a vendor contract with Vonage that dictates SDK support expectations? Was 2.4.0 accompanied by any maintainer statement of intent — a roadmap, a stated support window, a successor pointer — or is it silent? Is the 2020-era TLS/certificate path still valid in our egress environment?

Integration Approach

Stack fit. Poor as a forward-looking choice; now a serviceable stopgap rather than a marginal one. The correct target for a Laravel stack today remains vonage/client (with vonage/client-core) — PHP 8 support, current API coverage, an actual maintainer, and documentation that matches the code. What 2.4.0 buys us is the ability to run nexmo/client for a defined window without carrying known-vulnerable HTTP dependencies. It does not buy us a reason to start new work on it. The only defensible reason to touch nexmo/client is still an existing application already pinned to it.

Migration path. Still a rename, not a rewrite; the delta is marginally smaller now that both sides sit on Guzzle 7, but the sequence is unchanged:

1. Inventory every Nexmo\ import, config key (NEXMO_KEY, NEXMO_SECRET), facade alias, and service-provider registration. Flag anything currently pinned to Guzzle 6 — those are the installs 2.4.0 can break.
2. Add vonage/client on a branch; let Composer resolve the HTTP client rather than inheriting the metapackage's pin.
3. Mechanical namespace swap Nexmo\ → Vonage\, plus credential class moves (Nexmo\Client\Credentials\Basic → Vonage\Client\Credentials\Basic) and env var renames.
4. Isolate behavioral changes — Messages API payloads, signature verification helpers, response-shape differences — behind our own thin adapter (e.g. App\Sms\Sender) so future SDK churn costs one class, not a codebase.
5. Dual-run against sandbox credentials, then cut over and remove nexmo/client.

Compatibility. The PHP gate has moved but not disappeared. 7.2 is still below what any currently supported Laravel requires (Laravel 9 → PHP 8.0, 10 → 8.1, 11 → 8.2), so the decisive check is unchanged: run composer why-not php 8.x and confirm the package installs and passes tests on our actual runtime, not just that the constraint allows it. Second gate is the Guzzle major: confirm no co-installed package requires guzzlehttp/guzzle:^6. Third is PSR-18 discovery at bootstrap — better odds now, still worth an explicit smoke test.

Sequencing. Unchanged in order, changed in urgency: (a) freeze new usage of the package immediately; (b) audit for Guzzle 6 pins before the next composer update cycle runs, so 2.4.0 arrives deliberately rather than by surprise; (c) build the adapter seam so call sites stop depending on SDK types; (d) migrate to vonage/client behind that seam; (e) remove the metapackage. Do the adapter first — it is the step that makes the rest reversible and is valuable regardless of which SDK wins. 2.4.0 lets us schedule (d) rather than rush it, which is the correct read: the migration is now a planned piece of work, not an incident response.

Operational Impact

Maintenance. Effectively unchanged: near-zero upstream maintenance, so total cost still transfers to us. The specific line items improve — dependency-audit exceptions and manual Guzzle-6 security review largely go away — but the structural exposure remains: periodic re-verification that Nexmo endpoints still answer, and no commitment from anyone to patch this package if a CVE lands in client-core. Ownership should be explicit and single-threaded, not "the team." Treat 2.4.0 as evidence that someone is still watching, not as a support contract.

Support. Unchanged. No vendor support path. Vonage documentation, changelogs, and support tickets all assume vonage/client; any escalation still begins with "upgrade the SDK." One consequence of 2.4.0 worth noting: because the package now looks healthier on a dependency scanner, engineers are more likely to reach for it and then hit exactly this wall. Keep the internal guidance explicit — permitted only for existing integrations under migration.

Scaling. Unchanged. The SDK is a thin HTTP wrapper; throughput is bounded by Vonage account rate limits and our own connection management. Guzzle 7 is a modest improvement here — better connection reuse, PSR-18/PSR-7 middleware interoperability, so retry and backoff policies can be composed rather than reimplemented. But the metapackage still pins the client, which still limits our ability to standardize middleware across the estate. For high-volume messaging, queueing, idempotency keys, and explicit 429 backoff remain our responsibility, outside the SDK.

Failure modes. Two retire, one is added. Retired: Guzzle 6 CVE exposure, and the PHP-7.0-floor resolution failure on modern runtimes. Still live: 401/402 auth and billing failures surfacing as hard exceptions; 429 rate limiting under burst; webhook signature verification drift as Vonage rotates signing behavior; silent behavioral breakage when a retired endpoint returns 404/410 rather than a typed error; TLS/egress failures to the legacy API host. Added: major-version upgrade breakage from a routine composer update — Guzzle 6/7 conflicts or a PHP floor failure arriving unannounced on a minor semver bump. Instrument every send and every webhook verify with structured logging, and pin the version explicitly rather than floating the constraint.

Ramp-up. Unchanged. Low for a Laravel developer to send an SMS — hours. Medium for the full surface (Verify, Voice, Numbers, Messages, subaccounts, webhooks) because the tutorials and examples they will find online are for vonage/client, so every search result becomes a translation exercise. Estimate one engineer-day for a single-channel SMS integration, three to five for multi-channel plus webhook verification, and a half-day for the migration itself if we choose to do it now rather than later.

Recommendation. Do not adopt nexmo/client for new work — 2.4.0 lowers the cost of staying, not the cost of starting. Immediately audit the estate for Guzzle 6 pins so no application absorbs the Guzzle 7 bump by surprise, pin the version where the package is already in use, and keep the migration to vonage/client scheduled as a small piece of work behind an internal adapter. The risk profile improved from "migrate urgently" to "migrate on a planned date," and that is the correct amount of change to make.