Sendinblue Api Bundle Laravel Package

Getting Started

First, the honest framing: this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/sendinblue.php. It ships a Symfony Bundle class, a DI extension, and a config tree. Installing it in a Laravel app is not supported — Composer will pull it, but nothing will wire it up, and its Symfony ^2.x || ^3.x constraints will likely conflict with any modern Laravel (symfony/*: ^6/^7) dependency tree anyway. Treat this package as a reference for the SendinBlue V2 SDK wiring, not as something you composer require in a Laravel project.

Minimal steps if you were in a Symfony 2/3 app (the only place it works):

1. composer require sendinblue/sendinblue-api-bundle
2. Register new SendinBlue\SendinBlueApiBundle\SendinBlueApiBundle() in app/AppKernel.php (no Flex/auto-discovery era).
3. Configure it in app/config/config.yml under the bundle's config key with your API v2 key, sourced from parameters.yml — never hard-coded.
4. Run bin/console debug:container sendinblue to find the actual service ID the bundle registers (the exact ID and config key shape are not documented well outside the README; verify against the container rather than trusting blog posts).
5. First use case: a single transactional email — fetch the API client service, build the send request, call it, log the messageId.

What a Laravel developer should actually do instead:

1. composer require sendinblue/api-v3-sdk (or sendinblue/api-v2-sdk only if you are pinned to V2 for legacy reasons — don't be).
2. Bind the SDK client as a singleton in a SendinblueServiceProvider using config('services.sendinblue.key').
3. Add sendinblue to config/services.php and the key to .env.
4. First use case: a queued transactional email via a thin SendinblueMailer service, or a custom Laravel Notification channel.

Where to look first in the repo: the DependencyInjection/ folder (config keys and service definitions), then the README. That is the whole surface area — everything else is SDK passthrough.

Implementation Patterns

Since the bundle itself is a thin DI wrapper, the "patterns" that matter day-to-day are about how you expose a Mailin/SendinBlue client to application code. In a Laravel context, port the intent of the bundle rather than the bundle.

Singleton client + thin wrapper (the core pattern).

// app/Services/Sendinblue/Client.php
namespace App\Services\Sendinblue;

use SendinBlue\Client\Api\TransactionalEmailsApi;
use SendinBlue\Client\Configuration;

class Client
{
    public function __construct(private Configuration $config) {}

    public function transactional(): TransactionalEmailsApi
    {
        return new TransactionalEmailsApi(null, $this->config);
    }
}

Bind Configuration and the client as singletons in a service provider. This mirrors exactly what the Symfony bundle does with its DI extension — one configured client, injected wherever needed.

Mail transport integration. Register a custom Laravel mail transport so Mail::to(...)->send(...) routes through SendinBlue. This is the highest-leverage pattern: your existing Mailable classes and Blade views keep working, and only the transport swaps. The Symfony bundle does not give you this — it hands you an API client — so expect to write ~50 lines of adapter.

Notification channel. For SMS (sendTransacSms) and transactional email, implement toSendinblue() on notifiables and a SendinblueChannel. This keeps business logic out of controllers and gets queueing, retries, and failed() hooks for free.

Contact/list sync on domain events. Listen for Registered / OrderPlaced and dispatch() a job that calls ContactsApi::createContact with an updateEnabled = true upsert. Always queue it — the API is a network call and registration latency is user-visible.

Webhook ingestion. Add a dedicated route + controller for SendinBlue delivery/bounce events. The API v2/v3 SDKs do not validate signatures for you; implement your own shared-secret check and make the endpoint idempotent (store event IDs) before touching users.email_status or subscriptions.

Testing pattern. Type-hint your wrapper interface (SendinblueClient) everywhere, never the SDK class directly. In tests, $this->mock(SendinblueClient::class) — the SDK's generated API classes are painful to fake because their constructors want a Guzzle client and a Configuration.

Gotchas and Tips

• Archived since 2017, 14 stars, zero dependents. No security patches, no PHP 8 support, no Symfony 4+ support. Do not put this in a new project. Its only value is as an illustration of how to structure the DI wiring.
• V2 API is legacy. SendinBlue is now Brevo and V2 endpoints are on a deprecation path. Any tutorial you find that matches this bundle is teaching you an API shape you will have to migrate away from. Start on V3.
• The bundle is not a mailer. It does not register a Symfony SwiftMailer/Mailer transport and it does not give you templating. It exposes the raw SDK. If you expected sendinblue: { transport: ... } magic, that misconception will cost you an afternoon.
• Config tree is strict. Symfony bundle config trees reject unknown keys silently in some versions and loudly in others; if your api_key isn't picked up, check the Configuration.php in DependencyInjection/ for the exact key name before assuming the key is wrong.
• No auto-discovery. In Laravel there is nothing to discover, and in Symfony 2/3 you must hand-register the bundle. If services are "not found," this is almost always why.
• Exception handling is inconsistent across the SDKs. V2 throws SendinBlue\Client\ApiException with a response body string; parse it (json_decode($e->getResponseBody())) rather than string-matching the message. Catch at the job level and let Laravel's queue retry policy handle 5xx and 429; do not retry 400s.
• Rate limits and bursts. Bulk contact imports will hit per-minute limits. Chunk with ->chunk(100) and put a small sleep() or RateLimited job middleware between batches. The bundle gives you no throttling.
• Never log the API key or the raw request. Guzzle debug mode on will dump the api-key header into laravel.log — set Guzzle debug false in production and scrub the header if you add logging middleware.
• Extension point that actually matters: the SDK's Configuration object accepts a custom Guzzle HandlerStack. Use it to add retry middleware and a correlation-ID header rather than wrapping every call in try/catch/retry yourself.
• Sandbox first. Send a single email to a test address before wiring anything into a queued flow — the API returns 202 with a messageId even when the recipient is suppressed or the sender is unverified, so a green HTTP status proves very little.