Statamic Mailerlite Laravel Package

Getting Started

The concept7/statamic-mailerlite addon wires Statamic form submissions into MailerLite, so the fastest path is a newsletter/signup form you already have.

1. Install: composer require concept7/statamic-mailerlite
2. Publish the config: php artisan vendor:publish --tag=statamic-mailerlite (tag may vary by version).
3. Add MAILERLITE_API_KEY=... to .env. The key is a paid-plan MailerLite API token, not the legacy v2 key.
4. Open the form's YAML in resources/forms/<handle>.yaml and add a mailerlite entry under integrations.

First use case to validate the wiring: a single email field posting to a newsletter form, subscribing to one group. Confirm the subscriber appears in MailerLite, then layer on field mappings and multiple groups.

Implementation Patterns

Single-group signup (baseline). Configure the integration with the group identifier and map the email field. This is the simplest possible path and a good smoke test before touching segmentation.

Multi-group selection (new in 0.0.5). The integration now accepts multiple groups, so a submission can land in several MailerLite groups at once. Typical patterns:

• Static fan-out: subscribe every submission to a base group (e.g. "All subscribers") plus a topical group.
• Dynamic fan-out: map a checkbox/multi-select form field to groups so the visitor's interests determine segmentation.
• Regional/language fan-out: use a hidden field populated by the page or a Statamic conditional to tag the correct locale group.

Field mapping. Map Statamic form fields to MailerLite subscriber fields (email is required; name, company, custom fields are optional). Keep the mapping in the form YAML so it travels with the form definition and is reviewable in version control.

Compose with other integrations. The MailerLite integration is one entry in the integrations array. Leave the built-in email integration in place so the site owner still gets a notification, and let MailerLite handle the audience side.

Idempotency with duplicates. Decide upfront whether re-submitting should update an existing subscriber or be a no-op. MailerLite dedupes by email, but group membership and custom fields can still be updated on repeat submissions.

Gotchas and Tips

• Group identifiers are the usual failure point. MailerLite groups are referenced by ID, not by display name. Pull the IDs from the MailerLite dashboard (or the groups API) before configuring; a wrong ID silently drops the subscriber from that group.
• Watch the group → groups change. 0.0.5 introduces multi-group support. If your existing config uses the singular key, verify it still works after upgrading and migrate to the plural form. Test one subscription end-to-end after any bump, since this is a 0.0.x package where BC is not guaranteed.
• Integration failures can break the submission. Statamic form integrations run inline on submit; an unhandled MailerLite API error (bad key, rate limit, invalid group) can surface as an error to the visitor. Wrap risky config in testing and monitor Statamic's logs.
• Rate limits and latency. Each submission is a synchronous API call. For high-traffic forms, consider whether a queued listener or a scheduled sync is a better fit than inline submission.
• Caching group lists. If you build a dynamic dropdown of groups, fetch and cache the list rather than calling the API on every page render.
• Double opt-in lives in MailerLite. Whether subscribers must confirm is a MailerLite account/group setting, not something this addon controls — check it there if signups look "missing."
• Debugging path. Start with the Statamic form submission record (submissions show per-form), then the Laravel log for API errors, then the MailerLite subscriber search. That order isolates whether the problem is Statamic-side or MailerLite-side.
• Extension points. For anything beyond simple mapping (e.g. deriving groups from user data), prefer a custom listener/event over forking the addon; keep the addon's YAML config minimal and push logic into your own code.