PHPackages outkit/php-client - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [HTTP & Networking](/categories/http) 4. / 5. outkit/php-client ActiveLibrary[HTTP & Networking](/categories/http) outkit/php-client ================= Outkit PHP client 0.0.4(8y ago)115MITPHP Since Apr 16Pushed 8y ago1 watchersCompare [ Source](https://github.com/outkit/php-client)[ Packagist](https://packagist.org/packages/outkit/php-client)[ Docs](https://github.com/outkit/php-client)[ RSS](/packages/outkit-php-client/feed)WikiDiscussions master Synced 3d ago READMEChangelogDependencies (1)Versions (5)Used By (0) Outkit API Client ================= [](#outkit-api-client) This is the official PHP client for the [Outkit](https://outkit.io/) API. Installation ------------ [](#installation) Outkit is available as a Composer package. Add Outkit to your `composer.json` file like so: ``` composer require outkit/php-client # OR php composer.phar require outkit/php-client ``` Or you could just add it manually, like so: ``` { "require": { "outkit/php-client": "*" } } ``` Usage ----- [](#usage) ### Setup and authentication [](#setup-and-authentication) ``` // Use autolading to be able to use our classes without explicitly requiring them require __DIR__ . '/vendor/autoload.php'; // Instantiate a client by supplying API credentials $client = new Outkit\Client(array( "key" => "", // Fill in your API key "secret" => "", // Fill in your API secret "passphrase" => "" // Fill in your API passphrase (not your personal password) )); ``` You should figure out a way to get your credentials into your script without hardcoding them into your source files, like using environment variables. ### Submitting a message [](#submitting-a-message) Submitting a message for rendering and/or delivery will return a message record with the Outkit ID and the status set to `received`(as well as a few other properties that can be determined at creation time). The API call returns as soon as the message is saved on our servers, it does not wait for rendering or delivery to take place (by default - see the section on synchronous processing below). You can retrieve the status of a message at any time. We also support webhook notifications on status changes. ``` // Construct a message record $messageRecord = array( "type" => "email", // Message type - 'email' and 'sms' currently supported "project" => "my-project", // Project identifier "subject" => "Welcome, Jane!", // Email subject (optional, can also be set in the template or omitted for SMS messages) "template" => "my-template", // Template identifier "to" => "some.name@example.com", // Recipient address (and optional name) "from" => "other.name@example.com", // Sender address (and optional name) "data" => array( "name" => "John Doe", // ... // Add the values for any variables used in the template here ), ); // Then submit it $message = $client->createMessage($messageRecord); ``` ### Retrieving a message [](#retrieving-a-message) You can retrieve the status and data of a message at any time. After the message has been rendered, we will also return the applicable rendered fields (`subject`, `html_body` and `text_body` for emails, `text_body` for SMS messages) so that you can see exactly what was/will be sent. ``` $message = $client->getMessage("some-id"); ``` Return values ------------- [](#return-values) Both API calls return a single PHP stdClass with information about the message being submitted/inquired about. Which fields have content at any given time depends on which fields were submitted and the current status of the message. All JSON objects and arrays are translated to PHP stdClasses and Arrays. ``` object(stdClass){ "type" => "email", "id" => "578b072e-79e4-441e-b696-784aa744bf6e", "project" => "my-project", "template" => "my-welcome", "to" => "some.name@example.com", "from" => "other.name@example.com", "status" => "received", "subject" => "Welcome, Jane!", "html_body" => null, "text_body" => null, "data" => null, "created_at" => "2017-07-21T19:17:35.383277Z", "failed_at" => null, "queued_at" => null, "delivered_at" => null, "done" => false, } ``` So if the above was stored in `$message`, you could access *status* as `$message->status`. Rendering a message ------------------- [](#rendering-a-message) To support the use case of rendering a message using the Outkit infrastructure, but sending it yourself, you can specify `"render_only" => true` in the message record. Once the message has been rendered, its data will contain a `text_body` field (all types), and `subject` and `html_body`fields for emails. These can then be fed directly to, say, a Mailgun client or SMTP server. See details below. Synchronous processing ---------------------- [](#synchronous-processing) For some use cases (sending emails from scripts, using Outkit as a renderer etc.), it can be desirable to have the API calls operate synchronously - ie. attempt rendering/delivery immediately instead of queueing them, and return the rendered message and (optionally) its delivery status in the data from the API call. This can be accomplished by setting `"sync" => true` in the submitted message. Note that this will incur additional costs (see our pricing page for details), and that each Outkit customer is only allowed a limited number of such requests (currently 100.000 per month), since they are more difficult and costly for us to scale. Customers that need additional synchronous requests can contact support to have their monthly limit raised. Message lifecycle ----------------- [](#message-lifecycle) Submitted messages typically go through the following stages, which are reflected in the `status` field: - `received` - The message has been received and saved in our datastore, where it awaits further processing - `queued_for_rendering` - The message has been queued for rendering - `rendered` - The subject and HTML/text of the template have been rendered and merged with the submitted data - `queued_for_delivery` - The message has been queued for delivery - `delivered` - Message has been successfully delivered to the backend Typically, a message will go through all stages in a matter of milliseconds, but it can sometimes take a little longer. Note that different message can have different statuses. For example, a message with the `render_only` flag set will never be queued for delivery or delivered. Messages that supply their own `text_body` and `html_body` instead of using a template will never be rendered, only delivered. Note that the `delivered` status does not necessarily mean that the message has been delivered to the *end user*. Once the backend has accepted the message, it’s up to the backend to perform final delivery. Most backends offer webhooks if you need confirmation of the actual delivery. There are some additional statuses your message can have, in case of errors and problems: - `render_error` - We were unable to render the template with the submitted data - `backend_error` - We encountered an error when trying to submit the message to the configured backend - `internal_error` - There was an unrecoverable problem on our end (should be very rare) If the message has any of these statuses, there will be more information in the `status_message` field. Also, you can inspect the full backend response in the `response` field. All messages have a `done` flag (true or false) which indicate whether we have finished processing it. Nothing more will happen to a message once it is done, regardless of its status. A note on function names ------------------------ [](#a-note-on-function-names) The method names for messages (`getMessage` and `createMessage`) are deliberately generic, to align them with future expansions of the API (say, `createProject`). So even though you might feel like you are *submitting* or *sending* a message (and we often use terms like that in our own docs), in API terms you are always just `createMessage`-ing it. You’ll probably wrap our functions in your own `sendSms` or `enqueueEmail` or whatever anyway, so it shouldn’t be much of an issue. We feel that when dealing with APIs and their clients, consistency trumps linguistic accuracy. TODO ---- [](#todo) - Add proper tests with mocks - Add a way to access the full response ### Health Score 25 — LowBetter than 37% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity7 Limited adoption so far Community7 Small or concentrated contributor base Maturity56 Maturing project, gaining track record Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~5 days Total 4 Last Release 2935d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/a50acba84fdf1d1d89b1b34d9422db13b63042f645be0444b609498e53a8332d?d=identicon)[stiang](/maintainers/stiang) --- Top Contributors [![stiang](https://avatars.githubusercontent.com/u/94665?v=4)](https://github.com/stiang "stiang (18 commits)") --- Tags apiclientrestrestfuloutkit ### Embed Badge ![Health badge](/badges/outkit-php-client/health.svg) ``` [![Health](https://phpackages.com/badges/outkit-php-client/health.svg)](https://phpackages.com/packages/outkit-php-client) ``` ### Alternatives [nategood/httpful A Readable, Chainable, REST friendly, PHP HTTP Client 1.8k17.2M267](/packages/nategood-httpful)[arhitector/yandex PHP SDK для работы с некоторыми сервисами яндекса (Яндекс.Диск, Yandex.Disk) 13082.9k5](/packages/arhitector-yandex)[ismaeltoe/osms PHP library wrapper of the Orange SMS API. 4540.0k](/packages/ismaeltoe-osms)[labs64/netlicensingclient-php PHP wrapper for Labs64 NetLicensing RESTful API 1450.4k1](/packages/labs64-netlicensingclient-php)[bninja/restful Library for writing RESTful PHP clients. 1451.5k](/packages/bninja-restful)[msankhala/parsehub-php Php wrapper classes for Parsehub REST api. 1312.4k](/packages/msankhala-parsehub-php) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)