Sendinblue Laravel Package

Technical Evaluation

Architecture fit. siterig/sendinblue is a Statamic v5 addon — a Composer-installed Laravel package that almost certainly registers a service provider, publishes a config file, and hooks Statamic's form Submission event to POST a contact into Brevo (formerly Sendinblue) via API v3. That's the correct shape for this problem: single-purpose, no database tables, no Control Panel UI, no persistent state. The surface area is small (realistically 3–6 classes and a config array), which caps the blast radius of adoption. The honest counterargument is that this functionality is ~80–120 lines of listener code plus an env var; the package's value is configuration convenience and field mapping, not capability. Treat it as a shortcut, not a dependency.

Integration feasibility. Requirements are modest: Statamic 5.x on Laravel 10/11, PHP 8.2+, a Brevo account with an API v3 key, at least one list ID, and a form whose field handles map cleanly to Brevo contact attributes. Typical friction is not code but Brevo-side semantics — attributes must pre-exist or payloads get rejected/dropped, double opt-in is a Brevo template concern rather than a package concern, and GDPR/consent capture has to be modeled explicitly. A competent Laravel engineer can spike this end-to-end in under a day.

Technical risk. High relative to the value delivered:

• No validation signal. 0 stars, 0 dependents, composite score 1.80. There is no proxy for production usage, no community triage, and effectively a single-maintainer bus factor.
• Opportunity score 15.54 suggests low ecosystem pull — likely an internal extraction published for convenience rather than a maintained product.
• Unknown engineering hygiene. Metadata gives no evidence of tests, CI, static analysis, or a security policy. This must be verified by reading the source, not assumed.
• Third-party API coupling. Brevo v3 rate limits, attribute schema changes, and IP allowlisting behavior all sit outside your control.
• PII path. Form submissions are user-facing and carry personal data. A failure mode here means silently lost leads, which is a revenue problem, not an uptime problem.

Key questions.

1. Does it use the official Brevo PHP SDK or hand-rolled Guzzle calls? This determines the upgrade path when the API shifts.
2. Is the subscribe call synchronous inside the request, or dispatched as a queued job? Synchronous means form latency and form success are coupled to Brevo availability.
3. On failure, does it throw, log, or swallow silently? Can we make a failed subscribe visible and replayable?
4. Does it support double opt-in templates, DOI redirect URLs, and explicit consent field capture?
5. Is the outbound payload filterable (Laravel event/hook) so we can shape attributes without forking?
6. What is the license, and is the Composer constraint matrix (statamic/cms, laravel/framework, PHP) actually tested?
7. Does it conflict or race with other addons listening to the same submission event?

Integration Approach

Stack fit. Assumes a Statamic 5 site where contact capture flows through Statamic's native form pipeline ({{ form:contact }}). That's the happy path — drop-in install, publish config, map fields. If the front end is headless and posts to a bespoke controller, the addon's coupling to Statamic's form events may not apply, and you're better served by a thin in-house adapter calling Brevo directly.

Migration path. Greenfield: install, publish config, set API key and list ID in env/secrets, map handles, ship. Brownfield: if a Mailchimp or legacy Sendinblue listener exists, run both behind a config flag for one release cycle, reconcile contact counts between providers, then decommission the old path. Never cut over blind on a lead-capture flow.

Compatibility. Verify the Composer constraints explicitly rather than trusting the README: statamic/cms ^5.0, laravel/framework ^10|^11, PHP ^8.2. Confirm it targets Brevo API v3 and isn't pinned to a deprecated v2 endpoint. Check event-listener ordering if another addon (CRM, analytics, autoresponder) also subscribes to form submissions.

Sequencing.

1. Spike — local install, one form, one Brevo test list, confirm a contact lands with correct attributes and consent state.
2. Vendor review — read the full source (a few hours), verify license, tests, commit cadence, open issues, and the author's other packages.
3. Harden — wrap the integration behind an in-house adapter or listener so the package is replaceable; add queued dispatch and explicit error handling if absent.
4. Staging — Brevo test key, IP allowlist, form QA including failure injection (bad key, 429, timeout, unknown attribute).
5. Canary — one low-traffic form in production, monitored for 1–2 weeks.
6. Broaden — enable across remaining forms only after the canary reconciles cleanly.

Decision rule: adopt as-is if the spike passes and source review is clean. Fork-and-vendor into a private repo — or just reimplement in-house — if the listener is synchronous, untyped, or swallows errors. At this code volume, ownership is cheap and the supply-chain risk is not.

Operational Impact

Maintenance. Low code volume, but non-zero ownership. With 0 stars and 0 dependents you should assume you are the de facto maintainer: Brevo API drift, PHP/Laravel bumps, and Statamic 6 compatibility will land on your desk. Budget a few hours per quarter, plus a forced migration at the next Statamic major. Pin the version in composer.json and vendor the source if the repository goes quiet.

Support. No community, no issue history, no documentation beyond the README. An internal runbook is mandatory: where the API key lives, rotation procedure, which Brevo list and attributes each form maps to, and an escalation owner for "leads stopped appearing."

Scaling. Contact-form volume is typically tens to low thousands per day, so throughput is not the constraint. The real constraints are: (a) synchronous HTTP inside the user request, adding 100–500 ms and coupling form success to Brevo uptime; (b) Brevo per-second/per-minute rate limits under spam bursts; (c) no batching. Mitigate with a queue driver (Redis or database), ShouldQueue on the listener, exponential backoff, and a dead-letter store.

Failure modes.

• Silent swallow — submissions accepted, contacts never created, discovered weeks later. Highest-severity risk in the whole integration.
• Brevo 4xx on unknown attribute — contact rejected or partially created; needs pre-provisioned attributes and a validation test.
• Timeout / 429 — user sees a generic form error unrelated to their input, driving abandonment.
• Key rotation or revocation — total outage with no in-app signal; only detectable via monitoring.
• Duplicate contacts — email not used as the dedupe key, or updateEnabled misconfigured.
• Thread starvation — slow Brevo responses during a bot/spam burst degrade the whole site.

Mitigations: structured logging of every attempt keyed by submission ID, an alert on failed-subscribe rate, a try/catch that never blocks the user's success page, a replayable dead-letter table, and a weekly reconciliation of form submission count versus Brevo contact count.

Ramp-up. Half a day for a Laravel-fluent engineer to read the source and wire it up; a full day including Brevo account setup, DOI template configuration, attribute creation, consent copy, and QA. Add a day if queuing and observability must be retrofitted. After handover, marketing ops can own list and attribute management inside Brevo; they should not own the API key or the deployment.