Campaign Monitor Laravel Package

Product Decisions This Supports

Build vs buy for newsletter capture. Wiring Campaign Monitor by hand means: a Campaign Monitor API client with retry/error handling, subscriber create/update/unsubscribe calls, custom-field mapping, a control-panel UI for choosing the target list per form, an Antlers tag or two for frontend forms, and a fieldtype so editors can place signup fields in the page builder. That is realistically 3–6 engineering days plus ongoing API-drift maintenance. This addon is MIT-licensed and covers that surface, so the build-vs-buy call is "buy" unless we have requirements it structurally cannot meet (see below).

Roadmap items it unlocks cheaply:

• Newsletter opt-in on any existing Statamic form (contact, download, event registration) without a separate signup flow.
• Opt-in at user registration, so account creation doubles as list growth.
• Per-form list targeting, letting marketing route "product updates" vs "events" signups without an engineering ticket.
• Custom-field mapping, so subscriber attributes (plan tier, region, content interest) land in Campaign Monitor and drive segmentation there rather than in our app.

Decisions it should not be used to make. It is a write-path integration: subscribers go out, nothing comes back. Do not plan roadmap items around campaign performance, subscriber status read-back, or event-triggered journeys sourced from our app — those live in Campaign Monitor or need custom work. Equally, it is not an email sending library; transactional mail stays on our existing provider.

A note on the v3.0.1 release. The only shipped change is a fix to blueprint layouts under v6 — in Statamic terms, the control-panel fieldtype/blueprint definitions the addon registers. Product translation: on Statamic 6, editors may have seen the addon's list-selection field render incorrectly or not at all. If our roadmap includes upgrading to Statamic 6, this addon is now compatible at the fieldtype level and should be listed as a green item in that upgrade plan. If we stay on Statamic 5, the patch is inert and can ride along with normal maintenance.

Marketing-operations decision this forces: once list selection lives in the control panel, marketers own list routing and we own consent. That is a good split, but it must be written down — a content editor should never be the person deciding whether double opt-in is enabled.

When to Consider This Package

Adopt when most of these are true:

• The site is Statamic (this is an addon, not a general Laravel package — it buys you nothing outside Statamic).
• Campaign Monitor is already the email platform — existing lists, templates, sender reputation, and a contract. This is an integration, not a platform decision; it should not be used to justify switching ESPs.
• Newsletter capture happens on Statamic forms or user registration, which is exactly the two surfaces it covers.
• The marketing team wants to choose lists in the control panel rather than filing tickets.
• Signup volume is modest and one-way sync is sufficient — no need to suppress or re-target based on subscriber state pulled back into the CMS.
• We are comfortable with a small, single-maintainer, MIT addon (3 GitHub stars) pinned in composer.lock and verified on upgrade.

Look elsewhere when:

• Not on Statamic. Use the official Campaign Monitor SDK or a general Laravel wrapper — less indirection, same API.
• The ESP is undecided or likely to change. This addon hard-codes one vendor; committing to it before the ESP decision narrows options for no gain.
• You need bidirectional sync (subscriber state, engagement, custom-field read-back), bulk import, transactional sending, or event-triggered journeys driven by application behaviour. Those are custom-integration or vendor-SDK territory.
• You need a vendor SLA. Support is upstream GitHub issues only, on a short release cadence (a v3.x patch line already past a major bump). For a revenue-critical signup path, plan a fallback: the form should degrade gracefully if the API call fails, so a failed sync never blocks a submission.
• Compliance requires tighter control. Consent proof, data-processing agreements, and double opt-in configuration must be owned explicitly; this package does not enforce any of that for you.

How to Pitch It (Stakeholders)

For executives — the one-liner: A free, MIT-licensed Statamic addon that connects our forms and user registrations to Campaign Monitor, replacing roughly a week of custom API work with a configuration task, and giving marketing self-service control over which list each signup feeds.

Value: Faster list growth from traffic we already have (existing forms and registration become opt-in surfaces), no per-seat or licence cost, and no engineering involvement each time marketing wants a new signup placement. The vendor lock-in is to Campaign Monitor, which we already pay for — the addon adds no new dependency of consequence.

Cost and effort: Low. One Composer dependency, one published config, one list selection per form, one verification pass in staging. Budget a day of engineering plus a short legal/compliance review of consent wording and double opt-in settings.

Risk, stated plainly: this is a small, community-maintained package with a single primary contributor and a recent major-version churn in its blueprint handling — which is precisely what the current patch fixes for Statamic 6. Mitigations are cheap: pin the exact version, run one smoke test per signup form, make the Campaign Monitor call non-blocking so a sync failure never costs us a form submission, and record in our dependency log why we require ≥3.0.1 so future upgrades are not treated as arbitrary.

The ask: approval to adopt on the next Statamic 6 upgrade cycle, with marketing owning list routing, engineering owning consent enforcement and the failure path, and a named owner for the dependency. If we are not moving to Statamic 6 this quarter, defer to the next maintenance window — no urgency either way.