Vonage PHP SDK Core: sending SMS, voice and Verify calls from a PHP 8.1 application

What vonage-php-sdk-core actually covers

This is the PHP client library for Vonage's REST APIs. The README lists API support for SMS, Voice, Text-to-Speech, Numbers and Verify, the two-factor product, and the repository description adds messaging and two-factor authentication. The package is published on Packagist as vonage/client.

The intended user is a PHP developer who has a Vonage account and wants to call those APIs without writing request signing, response parsing and webhook validation by hand. The README points new users at the Vonage signup page before anything else, which tells you the library is not useful in isolation: it is a client for a paid account, not a general messaging framework.

One naming detail matters. The README notes that composer require vonage/client points to a wrapper library that includes an HTTP client and this core library, and that installing the core library directly lets you choose the HTTP client your project uses. So the repository name and the package most people install are not the same thing.

How the client, credentials and message objects fit together

The architecture visible in the README is a client object holding a credentials object, with API-specific sub-clients reached through accessor methods. You construct Vonage\Client with a credential instance, then call $client->sms()->send() to reach the SMS API. Configuration is passed as an array in the second constructor argument, where base_api_url overrides the default api.vonage.com host and base_rest_url overrides the host used for APIs that would normally hit rest.nexmo.com. That split exists because Vonage's estate spans more than one hostname, and the two keys let you redirect either group, which is how the README frames testing against something other than production.

Messages are objects, not arrays. An SMS is built from to, from and text, then passed to send(). The response is iterable: the README explains that a single SMS can be split into multiple messages, so the response contains one object per generated message, countable with count() and addressable with current() or a foreach loop. Each entry exposes getTo() and getRemainingBalance().

Encoding is handled explicitly rather than automatically. The README shows a static isGsm7() method on the SMS message class that you call yourself, then setType('text') or setType('unicode') depending on the result. That is a real design decision: the library gives you the predicate but leaves the branch to your code.

Installing the package and sending a first SMS

Installation goes through Composer. The README recommends composer require vonage/client, and the library requires a minimum PHP version of 8.1. Because that package is the wrapper, it brings an HTTP client with it; the README states you can install the core library directly from Composer if you want to choose the HTTP client yourself.

composer require vonage/client

After Composer finishes, include the autoloader in your bootstrap file. The README shows this exact line:

require_once "vendor/autoload.php";

Then create a client with your API key and secret. The credentials class is Basic, and the constructor takes the key and secret in that order:

$client = new Vonage\Client(new Vonage\Client\Credentials\Basic(API_KEY, API_SECRET));

Build a message and send it. The README's example passes the recipient first, then the sender, then the text, and uses a fluent setter for the optional client reference:

$text = new \Vonage\SMS\Message\SMS(VONAGE_TO, VONAGE_FROM, 'Test message using PHP client library');
$text->setClientRef('test-message');
$response = $client->sms()->send($text);

What you should see after send() is an iterable response. Pull the current entry and read the recipient and remaining balance:

$data = $response->current();
echo "Sent message to " . $data->getTo() . ". Balance is now " . $data->getRemainingBalance() . PHP_EOL;

For inbound messages, the README shows a webhook factory that reads the current request and a try/catch around it. Factory::createFromGlobals() returns an inbound object, and an InvalidArgumentException signals a malformed webhook:

try {
    $inbound = \Vonage\SMS\Webhook\Factory::createFromGlobals();
    error_log($inbound->getText());
} catch (\InvalidArgumentException $e) {
    error_log('invalid message');
}

Signed messages need a different credentials class

Message signing is the part of this library most likely to trip up a first integration. It is not enabled by default and it does not use your API secret. The README states that the SMS API can sign messages using a Signature Secret, with the algorithm agreed between your application and Vonage, and that the algorithm is selected in the account settings page of the dashboard. Supported values are md5hash1, md5, sha1, sha256 and sha512.

When signing is on, you do not use the Basic credentials class. You use SignatureSecret and pass the algorithm as a third argument:

$client = new Vonage\Client(new Vonage\Client\Credentials\SignatureSecret(API_KEY, SIGNATURE_SECRET, 'sha256'));

Inbound verification is separate. The README says signed webhooks carry sig, nonce and timestamp fields, and that you build a Signature object from the incoming data, your signature secret and the method, then call check() with the received sig value. The README's example reads from $_GET, which is worth noticing: it assumes the webhook parameters arrive as query parameters, and the library does not decide that for you.

Where the SDK stops being the right tool

The strongest limitation is scope. Every class in the examples is Vonage-specific: Vonage\Client, Vonage\SMS\Message\SMS, Vonage\Client\Credentials\SignatureSecret. If your roadmap includes switching or adding a second SMS provider, this library gives you nothing toward that. You would be writing your own abstraction above it, and the message objects would not map cleanly onto another vendor's model.

The PHP version floor is a hard constraint. The README states a minimum of PHP 8.1, so applications still on 7.x cannot use the current line at all, and the repository carries an UPGRADE-5.0.md file, which indicates a major-version migration path exists for projects moving onto it.

Configuration is thinner than the API surface suggests. The README documents exactly two constructor options, base_api_url and base_rest_url, both aimed at redirecting hosts. There is no documented retry policy, timeout key or connection-pool setting in the README, so anything in that area either lives in the HTTP client you chose or is undocumented. The README is also silent on rate limiting and on what happens when the API returns a partial failure across a multi-part SMS, beyond the fact that the response is iterable.

Finally, the library is a REST client, not a queue. It makes the call your process asks it to make. Delivery guarantees, retries and idempotency are your application's problem, not the SDK's.

Vonage-Laravel and other ways to reach the same API

The most direct alternative for PHP teams is Vonage-Laravel, the framework integration for Laravel applications. The difference is packaging and lifecycle, not protocol: it sits on top of a client like this one and adapts it to Laravel's service container, configuration files and facades. If you are on Laravel, that layer removes the manual autoloader and credential wiring shown in the README; if you are not on Laravel, it is dead weight.

The other real alternative is calling the REST endpoints directly with an HTTP client such as Guzzle. That keeps your dependency graph small and gives you full control over retries and timeouts, at the cost of implementing request signing, the signature check for inbound webhooks, and the response parsing that this library already provides. The README's own isGsm7() helper and the Signature class are the clearest examples of work you would otherwise repeat.

A third option is a provider-neutral messaging abstraction. That is the opposite trade-off: you gain portability between vendors and lose the Vonage-specific conveniences, including the webhook factory and the signed-message support documented here.

Licence, release cadence and upgrade cost

The repository is licensed under Apache-2.0, and the README carries the matching badge. Apache-2.0 permits commercial and closed-source use and includes an express patent grant, which is generally friendlier to corporate legal review than a bare MIT licence. This is a statement about the licence text, not legal advice; your own counsel decides what your distribution model requires, particularly the notice and attribution obligations.

Maintenance signals are mixed but concrete. The last push to the default branch was on 2026-07-15, and release 4.14.0 is dated the same day, with 4.13.0 on 2026-03-31 and 4.12.0 on 2026-01-06. The repository is not archived, so it is still being worked on, but the gaps between releases are measured in months, not weeks. Plan upgrades around that cadence rather than expecting continuous change.

Upgrade cost is front-loaded. The presence of UPGRADE-5.0.md means a major-version break happened and the project documented the migration. The README's PHP 8.1 minimum is the other cost centre: it forces an upgrade of your runtime before the library will install. Because the composer.json, phpstan configuration and phpunit configuration are all in the repository root, the maintainers run static analysis and a test suite against the code, which is a reasonable signal that a version bump is not cosmetic.

Editorial conclusion

Adopt vonage-php-sdk-core if your application already bills through Vonage and you want webhook parsing, message signing and typed response objects without hand-rolling HTTP calls. Do not adopt it if you need a provider-neutral interface, since every message object and client class is Vonage-specific, or if you are stuck below PHP 8.1. Before committing, verify three things: that composer require vonage/client resolves the wrapper rather than the core package, which HTTP client the wrapper pulls in, and whether your account has message signing enabled, because that changes which credential class you instantiate.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Vonage/vonage-php-sdk-core on GitHub