splash/sendinblue
A Laravel package for integrating Sendinblue (now Brevo) into your applications. Send transactional emails and SMS, manage contacts, and access common API operations through a simple, fluent wrapper with streamlined configuration.
Architecture fit. Despite being listed as a Laravel/PHP package, splash/sendinblue (repo: SplashSync/Brevo-Bundle) is a Symfony bundle, not a Laravel package. It is a connector within the SplashSync hub-and-spoke synchronization framework, and the "Embedded" designation means the Brevo API client is vendored inside the bundle rather than depending on a separate SDK. It is architecturally appropriate only if we are already committed to SplashSync as the integration backbone; it is not a general-purpose Brevo SDK. For a Laravel codebase it provides no service provider, facade, or config publishing — it would require either a Symfony-compatible host, a bridge layer, or running Splash as a sidecar service.
Integration feasibility. Installable via Composer and configured with a Brevo API key plus Splash endpoint credentials. The real integration cost is not the package but the Splash core dependency it presumes: connector registration, object mapping definition, and sync configuration. As a Brevo client in isolation it covers a narrow surface (contacts, lists, and whatever Splash exposes as syncable objects) rather than the full Brevo API (campaigns, transactional email, templates, webhooks). Feasibility is therefore conditional: high inside a Splash deployment, low-to-moderate as a standalone Laravel dependency.
Technical risk. The adoption signals are the headline risk: 0 stars, 0 dependents, single-vendor maintenance (SplashSync), and a package name that still references SendInBlue, the pre-rebrand identity. This suggests either a very recent rename or a stale artifact — both require verification before commitment. Because the HTTP client is embedded, it does not automatically inherit upstream Brevo SDK fixes; API version drift (legacy SendInBlue v2 vs. current Brevo v3 endpoints) becomes our problem to detect. MIT licensing is clean and carries no legal friction. Supply-chain exposure is low-volume but unvetted: no evidence of test coverage, CI, or security scanning in the summary.
Key questions.
Stack fit. Poor for a pure Laravel application; adequate for a Symfony application; strong only within an existing SplashSync footprint. Laravel already consumes several Symfony components, but bundle registration, DI extension loading, and kernel bootstrapping are not Laravel mechanisms. Expect to either (a) run Splash as a separate Symfony service and integrate over HTTP/queue, or (b) invest in an adapter layer that is itself unmaintained-by-vendor. Neither is free.
Migration path. The SendInBlue → Brevo rebrand is the critical migration axis. Confirm whether the embedded client targets deprecated api.sendinblue.com v2 endpoints or the current Brevo v3 endpoints. If legacy, plan a fork-and-patch or an early exit before we build workflows on top. Run any migration as a dual-write / shadow-sync exercise: keep the incumbent provider authoritative, mirror into Brevo through this connector, and diff results before cutting over.
Compatibility. Verify three axes independently — PHP version, Symfony major version, and Brevo API version — plus the transitive Guzzle/HTTP client version. Pin all of them in composer.json with a lockfile committed. Because the client is embedded, an API-side change will not surface as a Composer update; it will surface as a runtime failure, so compatibility has a time dimension that dependency pinning alone does not control.
Sequencing.
Maintenance. We inherit de facto maintenance. With no dependents there is no community patch flow, no issue triage signal, and no third-party bug reports to learn from. Budget for a named owner, a vendored fork under our org, and a quarterly review of the Brevo API changelog. Treat the embedded client as internal code from day one rather than as a maintained dependency.
Support. Vendor support only, with no public documentation ecosystem, no Stack Overflow corpus, and no community Slack. Mean time to resolution for an API drift incident is effectively bounded by our own engineers' Brevo knowledge, not by the vendor's SLA.
Scaling. Throughput is governed by Brevo's account-tier rate limits, not by the bundle. Contact sync is batch-friendly and will scale acceptably; campaign or transactional workloads will hit per-second and daily quotas and need backoff and queueing that the bundle likely does not own. Plan for queue-based dispatch, idempotency keys on writes, and observable retry state rather than assuming the connector handles it.
Failure modes. The realistic incident set: (1) silent endpoint deprecation after a Brevo API change; (2) API key rotation without a config reload path; (3) rate-limit exhaustion under backfill; (4) partial-sync divergence between source system and Brevo with no reconciliation tooling; (5) Composer resolution conflicts on Symfony components during unrelated framework upgrades; (6) abandonment — repository archived or unreleased for extended periods with no fork ready.
Ramp-up. Low for an engineer already fluent in SplashSync's object-mapping model; high otherwise, because the package's real complexity lives in Splash abstractions the bundle does not explain and the broader ecosystem does not document. Add roughly one to two weeks of onboarding for a team new to Splash, and assume the first engineer to touch this becomes the sole internal authority — a bus-factor of one unless deliberately mitigated.
How can I help you explore Laravel packages today?