Library / SDK
sendgrid/sendgrid-php avatar
sendgrid/sendgrid-php

sendgrid-php: Web API v3 Access for PHP Applications

The Official Twilio SendGrid PHP API Library

1,519 stars609 forksPHPMIT

At a glance

What is it?
sendgrid-php is the official PHP client for the Twilio SendGrid Web API v3, covering email delivery and account API resources through fluent or path-based requests. It suits PHP applications already using SendGrid, but its documented Composer constraint needs review before adoption.
Who is it for?
Adopt sendgrid/php when a PHP application already depends on SendGrid and its supported endpoint coverage fits the required Web API v3 calls. Do not adopt it solely for basic SMTP sending or for a new project until you verify the intended major version, authentication storage, PHP compatibility, and the exact endpoint behavior you need.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 120 days ago.
What is it written in?
Mainly PHP, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What sendgrid-php Covers for SendGrid Applications

sendgrid-php addresses the gap between PHP application code and the Twilio SendGrid Web API v3. It is intended for developers who need to send transactional email or work with SendGrid account resources from PHP. The README states that version 7.X.X supports the full set of Twilio SendGrid Web API v3 endpoints, including the v3 `/mail/send` endpoint.

Its scope extends beyond constructing and submitting a message. The repository includes examples for access settings, alerts, API keys, campaigns, categories, contact database resources, devices, IP addresses, mail settings, sender authentication, senders, statistics, suppression lists, templates, users, and related Web API areas. Those examples indicate a client library rather than a narrowly focused SMTP transport. SMS is also mentioned as a use case, with Twilio account access required for that workflow.

The central trade-off is coupling. A PHP application using sendgrid/php is making API calls through SendGrid, so it needs a SendGrid service and a `SENDGRID_API_KEY`. It is therefore a poor fit for an application that only needs to submit SMTP messages through an existing mail transport, or one that wants to avoid direct dependence on SendGrid. Conversely, it is a sensible candidate when the application already needs SendGrid-specific capabilities such as templates, suppression resources, statistics, or sender configuration.

Mail Object Construction and SendGrid API Requests

The mail path begins with `\SendGrid\Mail\Mail`. Developers set the sender, subject, recipient, and one or more content parts on that object. A `\SendGrid` instance is then constructed with the API key and receives the completed mail object through `send()`. The call returns an HTTP response wrapper whose documented accessors include `statusCode()`, `headers()`, and `body()`.

That design separates message assembly from request execution. `SendGrid\Mail\Mail` represents the message payload, while `\SendGrid` carries the client credentials and submits it. The README links the mail constructor's personalization behavior to the SendGrid v3 Mail Send documentation and directs developers to `USE_CASES.md` for more advanced examples, including a transactional template.

For non-mail resources, the library exposes a generated-looking client tree under `$sg->client`. The README's suppression example calls `suppression()->bounces()->get()`. This is the fluent interface: each method selects an API resource and operation before sending the request. Developers who need or prefer a direct path can instead call the underscore method with `suppression/bounces` and then `get()`.

The fluent form is easier to scan for known resources, while the path form exposes the API route more directly. The latter can also be useful when a method wrapper does not cover a desired endpoint. However, the README does not say that the direct path form bypasses validation or authentication, so it should be treated as another access style, not as a lower-level protocol implementation.

Composer Installation and the sendgrid-php Version Constraint

The documented prerequisites are PHP 7.3 or later and access to the Twilio SendGrid service. Applications that use Composer add `sendgrid/sendgrid` to `composer.json`. The README currently shows the following constraint:

json
{
  "require": {
    "sendgrid/sendgrid": "~7"
  }
}

This constraint permits compatible 7.x releases but excludes 8.x releases. That matters because the repository's recent release list identifies 8.1.11 as the latest listed release, and the ZIP alternative points to `8.1.11`. The README also contains legacy wording about version 7.X.X even though the listed package releases are in the 8.1.x line.

Developers should not silently align the Composer requirement with the ZIP link. Choosing a major version requires checking `composer.json`, `CHANGELOG.md`, `UPGRADE.md`, and the release notes for that specific line. The documented repository contains those files, but the README does not describe the compatibility changes between the two major versions. The practical issue is dependency resolution: `~7` will not select 8.1.11.

The Makefile's `install` target is stricter than the README's abbreviated package instruction. It removes `vendor` and `composer.lock`, then runs `composer install`. Developers should avoid treating that repository-development target as a routine application deployment command, especially in a repository that tracks `composer.lock`.

Environment Setup and the First Email Submission

The repository includes `.env.sample` with the exact environment variable used by the examples. For local setup, the README instructs developers to copy it, populate the key, and source it. The copy and source commands are:

bash
cp .env.sample .env
source ./.env

Between those commands, edit `.env` so that `SENDGRID_API_KEY` contains the API key created through SendGrid's API key settings. The sample file exports the variable with an empty initial value:

bash
export SENDGRID_API_KEY=''

The first email example can be placed in a PHP file after including the appropriate autoloader. Composer users normally load `vendor/autoload.php`; ZIP users load the distributed `sendgrid-php.php` file. The core request is short enough to serve as a first use, but the catch block matters. It converts an exception into visible output instead of treating a failed API submission as a delivered message.

Success still requires inspecting the response status and body rather than assuming that constructing a `Mail` object sends anything. The example prints all three response components. Developers adapting it to an application should preserve that visibility or map the API result into the framework's existing error handling. The README does not specify status-code meanings, retry rules, or idempotency behavior, so those details must come from SendGrid's API documentation rather than inference from this client example.

Composer Dependency Management Versus the Packaged ZIP

Composer and the packaged ZIP are the project's two documented installation approaches. Their difference is concrete. Composer records `sendgrid/sendgrid` as a declared package dependency and manages its transitive dependencies according to the application's Composer setup. The Makefile identifies `php-http-client` as dependency-free, which reduces the dependency chain even though Composer is still the package manager.

The ZIP route downloads the library's packaged release and includes it without adding the package to `composer.json`. For a ZIP installation, application code manually includes `sendgrid-php.php` rather than the Composer autoloader. This can suit a deployment that cannot use Composer, but it moves responsibility for obtaining and retaining the chosen release to the developer.

The README links the current packaged download to 8.1.11 and provides a release directory for earlier versions. That makes the ZIP path flexible for version selection. It does not document whether the ZIP is equivalent to a Composer install in autoloading, generated API coverage, or other runtime behavior. Based on the repository layout, the Composer package can be integrated through the normal application dependency system, while the ZIP requires direct inclusion.

The `Dockerfile` is designed for repository development rather than a user-facing container image. It accepts a PHP image version through `ARG version=latest`, installs Composer and GMP, copies the project into `/app`, and runs `make install`. Its default `latest` value and development commands mean it should not be mistaken for a documented production deployment image.

Testing, Maintenance Signals, and Upgrade Boundaries

The `Makefile` documents three main quality checks: unit tests, coding standards, and static analysis. Its `test` target invokes PHPUnit for unit tests, PHPCS for `lib/*/*`, and PHPStan for `lib` and `test`. The `test-integ` target runs unit checks first and then invokes PHPUnit against the wider test suite. Docker-based testing selects either the lowest stable dependencies or the highest dependencies through Prism.

These commands are relevant to contributors and maintainers, not to every application that consumes the package. The Makefile's `clean` target removes `vendor`, `composer.lock`, and `sendgrid-php.zip`. Because `ci-install` also depends on `clean`, even production dependency installation through that target removes the local lock file before running Composer. This repository workflow deserves attention during contribution, but it is separate from using the released library.

The repository is not archived, and its last push was on 2026-06-25. The latest listed release is 8.1.11, published on 2025-02-22, following 8.1.10 on 2025-02-11 and 8.1.9 on 2025-01-28. These dates establish repository and release activity, but the README does not state a support window or compatibility policy for PHP versions and API endpoint changes.

Upgrade planning should therefore be version-specific. `UPGRADE.md` and `CHANGELOG.md` are named in the repository, but the README does not describe their contents. There is also a mismatch between the README's `~7` constraint and its 8.1.11 release references. That mismatch is the clearest documented maintenance boundary for a prospective adopter. The MIT license permits use, modification, distribution, and merging under its terms, subject to the license text, but it does not answer whether every 8.x release is compatible with an application written for 7.x.

Editorial conclusion

Adopt sendgrid/php when a PHP application already depends on SendGrid and its supported endpoint coverage fits the required Web API v3 calls. Do not adopt it solely for basic SMTP sending or for a new project until you verify the intended major version, authentication storage, PHP compatibility, and the exact endpoint behavior you need. The first check should be the `sendgrid/sendgrid` constraint in the application's `composer.json`, because the README currently shows `~7` while its downloadable ZIP points to release 8.1.11.

Frequently asked questions

What PHP version does sendgrid-php require?

The README lists PHP 7.3 or later as the prerequisite. It does not provide compatibility details for specific 8.x package releases.

How do I install sendgrid-php with Composer?

Add `sendgrid/sendgrid` to `composer.json`, but first resolve the README's version discrepancy. It documents `~7` while linking the packaged release for 8.1.11.

How does sendgrid-php send its API key?

The examples read `SENDGRID_API_KEY` with `getenv()` and pass the result to `new \SendGrid($apiKey)`. The README does not describe credential caching or redaction behavior in the client.

Official sources

  1. License: MIT
  2. Project website
  3. README
  4. Releases
  5. sendgrid/sendgrid-php on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/sendgrid-sendgrid-php.svg)](https://hysenlabs.com/projects/sendgrid-sendgrid-php)

Was this useful?