Statamic Mailerlite Laravel Package

Technical Evaluation

Architecture fit. concept7/statamic-mailerlite is a Statamic v3/v4 addon (Laravel package) that bridges Statamic form submissions to the MailerLite API. It fits our stack only if Statamic is already the CMS layer — it is not a general-purpose Laravel MailerLite client and should not be evaluated as one. Release 0.0.5 adds multi-group selection, meaning a single form submission can now map a subscriber into several MailerLite groups rather than one. This is a genuine functional improvement for segmentation use cases (e.g. newsletter + product interest + region), not a cosmetic change.

Integration feasibility. Composer-installable, auto-discovered service provider, configuration-driven. Integration effort is low: install, publish config, supply a MailerLite API token, and configure group mappings on the form/field. The multi-group feature reduces the need for custom event listeners or duplicate submissions to fan out into multiple groups — previously we would have had to write glue code for that. Feasible within a single sprint for a standard form-to-list workflow.

Technical risk. Material, and mostly not about this release:

• 0.0.x versioning. Still pre-1.0 after five releases. No semver contract, so minor bumps can carry breaking config changes. Must be pinned exactly in composer.json.
• Probable config-shape change. Moving from one group to many almost certainly changes the stored field/config value from a scalar group ID to an array. Existing Statamic YAML configs and any templates reading that value may need migration. This is the single most important thing to verify before upgrading — see Integration Approach.
• Single-maintainer package (concept7 / one contributor). Bus factor of one, small install base, no visible long-term support commitment. Budget for the possibility of forking.
• External API coupling. Behaviour is bounded by MailerLite API limits, rate limiting, and token lifecycle; the package is a thin wrapper and offers little resilience on top.

Key questions.

1. Does 0.0.5 change the config key/schema (e.g. group → groups), and is the old scalar form still accepted for backwards compatibility?
2. Is the multi-group write a single API call or N sequential calls per submission? This directly affects form latency and rate-limit exposure.
3. What is the failure behaviour if one group in the set is invalid or deleted in MailerLite — partial success, full rollback, or silent skip?
4. Which Statamic and Laravel versions are supported, and is the addon compatible with our current Statamic minor?
5. Is there any test coverage or CI on the repo, or are we validating behaviour ourselves in staging?

Integration Approach

Stack fit. Requires a Laravel + Statamic application; the addon piggybacks on Statamic's form submission lifecycle and its own config/asset publishing. It does not conflict with our queue, cache, or auth layers and introduces no new infrastructure. If Statamic is the CMS, this is the lowest-friction MailerLite integration available; if not, reject it and use the official MailerLite SDK directly.

Migration path. Treat 0.0.5 as a config-touching upgrade, not a drop-in patch:

1. Pin to 0.0.4 in production; branch for the upgrade.
2. Diff the published config file between 0.0.4 and 0.0.5 in staging and identify renamed/reshaped keys.
3. Search the codebase and Statamic content/forms YAML for the old group field and migrate any scalar values to arrays.
4. Re-run a real form submission against a MailerLite test account and confirm the subscriber lands in all expected groups.

If the old scalar form is still accepted, the upgrade can be rolled out without a data migration; if not, sequence the config migration ahead of the deploy.

Compatibility. Verify against our pinned Statamic minor before upgrading — pre-1.0 addons frequently track only the latest Statamic release. Also confirm the MailerLite API version targeted by the wrapper hasn't shifted.

Sequencing. (1) Pin current version and confirm token/config baseline; (2) upgrade in staging, validate config diff; (3) migrate configs/templates; (4) end-to-end test with a test MailerLite account, including a form that maps to multiple groups; (5) roll out to production behind normal release process; (6) only then refactor/remove any custom multi-group glue code we previously wrote.

Operational Impact

Maintenance. Low ongoing effort but non-zero risk: expect to review each 0.0.x release manually rather than accepting automatic updates. Because the package is a thin wrapper, most maintenance work is token rotation and MailerLite API change tracking, not code. Recommend pinning exactly and adding it to a quarterly dependency review, with a documented fork path if the maintainer goes dormant.

Support. No commercial support; reliance on GitHub issues with a single maintainer. Internal ownership must be assigned explicitly — otherwise this becomes orphaned at the first incident. Document the config schema and group mapping in our runbook so a second engineer can debug without reading the package source.

Scaling. Submission path is synchronous by default; multi-group writes may increase per-submission API calls and latency. For high-volume forms, wrap submissions in a queued job so MailerLite latency or outages never block the user-facing request. Watch MailerLite rate limits as form volume grows — this is the most likely scaling ceiling, not the package itself.

Failure modes. (a) API timeout or 5xx during submission — user-facing form failure or lost subscription; mitigate with queueing and logging. (b) Invalid/expired API token — silent non-delivery of subscribers; mitigate with an alerting check. (c) Group deleted or renamed in MailerLite — with multi-group, one bad ID could fail the whole write or silently drop that segment; verify behaviour explicitly. (d) Config-shape drift on upgrade — subscribers quietly routed to a default or no group. Each of these is silent by nature, so structured logging around every MailerLite call is a requirement, not a nice-to-have.

Ramp-up. A Laravel developer can be productive in under a day; the surface area is small. The real ramp-up cost is understanding Statamic form/field configuration, not the package. Plan for one engineer to own the upgrade and validation, plus a reviewer for the config migration.