Statamic Acumbamail Laravel Package

Technical Evaluation

Architecture fit This is best understood as a Statamic 5 addon rather than a standalone Laravel package — the "CP interface" (Control Panel), "site configuration", and multi-site support are Statamic-specific concepts. The Laravel 11/12 and PHP 8.2+ requirements are inherited from Statamic 5's platform baseline, not independent compatibility claims. That matters for scoping: the package is only relevant to teams already running (or planning) Statamic 5. Teams on plain Laravel, Blade/Livewire, or Nova derive no value from the CP surface and would be paying for a UI they cannot use.

Functionally the package is thin and well-bounded: form configuration → list selection → merge-field mapping → Acumbamail subscribe call, with double opt-in delegated to the provider. That is a sensible architecture — consent and confirmation state live in Acumbamail rather than being reimplemented locally, which reduces the surface area we own.

Integration feasibility Feasible for a greenfield Statamic 5 build. Requirements are explicit and narrow: Statamic 5, Laravel 11/12, PHP 8.2+, an Acumbamail account, and API credentials. The Free edition covers core subscription, so we can validate the integration end-to-end at zero licence cost before committing to Lite or Pro.

The main feasibility unknown is edition gating. Merge field mapping is listed as available in both Lite and Pro, while multi-site is Pro-only. We need the actual edition matrix before scoping a multi-site build, because multi-site is the differentiator that would justify Pro and it is the one capability we cannot trial on Free.

Technical risk

• Maturity risk (high): v1.0.0 is an initial release. No prior version history, no stated deprecation policy, no evidence of a test suite or CI. First-release addons typically shake out breaking changes in the first two or three minors.
• Vendor concentration (medium-high): Acumbamail is a Spain-centric email marketing provider. Adopting this addon effectively selects Acumbamail as our ESP. Switching later means re-implementing the integration, not just swapping a config value. Confirm whether the package exposes any abstraction layer or calls the Acumbamail SDK directly.
• Delivery reliability (medium): The notes describe synchronous subscribe behaviour and do not mention queueing, retries, rate-limit handling, or failure logging. If subscription calls are made inline during form submission, an Acumbamail slowdown becomes our form's latency and a provider outage becomes a lost subscriber.
• Compliance surface (medium, but favourable): Double opt-in and explicit consent fields are included, which is a genuine GDPR plus for an EU-facing site. The open question is where consent evidence is stored — if it is only in Acumbamail, our own audit trail depends entirely on the vendor.
• Single-maintainer risk (medium): No indication of maintainer count or commercial backing. A v1.0.0 addon with an edition-based revenue model is more likely to be sustained than a hobby project, but this needs verifying.

Key questions

1. What is the exact Free / Lite / Pro feature and price matrix, and is the licence perpetual or subscription?
2. Is the Acumbamail API called synchronously on form submit, or is there a queue/job path?
3. How are API errors, rate limits, and timeouts surfaced — CP log, Laravel log, silent failure?
4. Where is consent evidence persisted, and for how long?
5. Are Acumbamail webhooks (confirmation, unsubscribe, bounce) consumed, or is the integration one-way outbound only?
6. What is the upgrade mechanism and cost from Free → Lite → Pro, and does it require a reinstall?
7. Is there a test suite, CI pipeline, and stated support window for Statamic 5?
8. What happens to stored configuration and consent data on uninstall?

Integration Approach

Stack fit Narrow but clean. This only fits a Statamic 5 site on Laravel 11/12 and PHP 8.2+. It does not fit Statamic 4, Laravel 10, or PHP 8.1 environments, and there is no stated backward-compatibility path. Before anything else, confirm our target environment's Statamic and PHP versions — if we are mid-upgrade, this addon becomes a forcing function on the platform upgrade rather than an independent decision.

Acumbamail's regional strength (Spain, LATAM) should be checked against our audience. If our list is primarily non-EU, we should scrutinise deliverability reputation and localisation of the double opt-in emails before adopting.

Migration path Greenfield only. There is no prior version, so no upgrade migration exists and none is needed. There is also no migration path from another ESP — moving an existing list means exporting and re-importing into Acumbamail out of band, and re-consenting contacts if the original consent basis does not carry. Budget for that as a separate workstream if we have an existing list.

Compatibility The compatibility matrix is effectively a single point: Statamic 5 / Laravel 11–12 / PHP 8.2+. That is a pinned, current stack, which is good hygiene for a new addon but leaves no slack. We should assume we upgrade Statamic and PHP in lockstep with this addon, and verify the maintainer's stated support window before depending on it.

Sequencing

1. Validate on Free, single-site, non-production. Install, wire one form, complete a real double opt-in against a test Acumbamail list, and confirm contacts and merge fields land correctly.
2. Probe failure behaviour before building on it: revoke the API key, throttle the network, and observe what the submitting user sees. This determines whether we need our own queue and fallback.
3. Resolve the edition decision. Only pursue Pro if multi-site is a real requirement — otherwise Lite (merge fields) plus Free covers the documented feature set at lower cost and lower commitment.
4. Pilot on one production site with a low-traffic form before rolling out across the estate.
5. Re-assess at v1.1.x. Treat v1.0.0 as a trial-grade dependency; do not standardise on it until it has one or two maintenance releases behind it.

Operational Impact

Maintenance Low code footprint, but the maintenance burden sits with a single small vendor and an initial release. We inherit the vendor's release cadence as a constraint on our own Statamic and PHP upgrade schedule — a stalled addon blocks a platform upgrade. Add it to the dependency register with an explicit owner and a review trigger on every Statamic major.

Support No stated support tier, SLA, or response commitment. If we adopt Pro, clarify what commercial support is included; if we stay on Free, assume community-only and plan for self-support. For a system that gates marketing consent capture, self-support is a real risk to a compliance-relevant workflow.

Scaling Throughput is bounded by the Acumbamail API, not by our infrastructure. Two scaling limits to establish early: Acumbamail's rate limits on our plan tier, and whether subscribe calls are queued. If they are synchronous, form submission latency becomes a function of third-party response time and will degrade visibly under campaign-day load. If we anticipate high-volume or bursty signup (paid campaigns, events), assume we need to wrap submissions in a queued job ourselves.

Failure modes

• Acumbamail outage or timeout: subscribers lost or the form errors in front of the user. Mitigation depends entirely on whether retries/logging exist — currently undocumented. Treat as unmitigated until proven otherwise.
• Invalid or expired API credentials: likely surfaces as silent non-subscription. Requires monitoring, not just configuration.
• Merge field drift: if a field is renamed or removed in Acumbamail, mappings break without a validation step. Needs a periodic check.
• Double opt-in non-delivery: confirmation emails can land in spam, quietly suppressing list growth. Deliverability monitoring is required and is not something this addon provides.
• Uninstall / vendor change: consent records may live only in Acumbamail, so leaving the vendor means losing the audit trail.
• Silent consent failure: the worst case — a user believes they subscribed, no record exists, and we cannot evidence consent. This is the failure mode to design a test around.

Ramp-up Fast for developers already fluent in Statamic — CP-driven configuration means most setup is point-and-click, and the Free tier removes procurement friction from the initial evaluation. Realistically half a day to a working single-site integration, plus a further day for failure-mode testing.

The ramp-up cost is not developer time; it is decision time. Someone must own the edition choice, the ESP vendor decision, and the consent-record retention policy. Those are product and legal calls, not implementation tasks, and they should be resolved before the pilot rather than after.