Campaign Monitor Laravel Package

Technical Evaluation

Architecture fit

This is a Statamic addon, not a standalone Laravel package — it extends Statamic's form-submission pipeline and user-registration lifecycle and exposes Campaign Monitor as a first-class CP resource. That placement matters for a TPM: it means the integration surface is content-editor-facing (mailing list selection, custom field mapping, subscriber management in the control panel) rather than a headless SDK we'd wire ourselves. The value proposition is glue removal — newsletter signup, unsubscribe, and subscriber updates become configuration plus Antlers markup instead of bespoke Campaign Monitor API v3 client code we maintain forever. Architecturally it fits any Statamic site that already uses Statamic Forms or native user registration; it fits poorly if our forms live in a separate app, if we use a different ESP as the system of record, or if we need behaviour Campaign Monitor's list model does not support (complex journeys, transactional sends, deep segmentation).

Integration feasibility

High in shape, medium in confidence. The install path is standard: Composer require, publish config, supply API credentials and list IDs, map custom fields, then attach the fieldtype to a form blueprint or use the Antlers tags. No database migration or schema change is advertised. The real feasibility work is not code — it is consent design and list hygiene: deciding whether user registrations auto-subscribe (a compliance decision, not a technical one), whether we want single or double opt-in, and which Campaign Monitor custom fields must pre-exist in the CM UI before mapping works. Budget days, not weeks, but do not treat this as a drop-in toggle for anything touching user registration.

Technical risk

• Low: MIT licence, stateless integration (no owned data model), and the package is a thin adapter over a stable third-party API. Removal is a composer remove plus config deletion — low lock-in at the code level.
• Moderate: low adoption signal (3 stars) and a small maintainer surface. The code may be excellent — Rad Pack is an established Statamic shop — but low visibility means few strangers hitting edge cases, so we will likely be first to find them.
• Moderate: compliance risk dominates technical risk. Syncing user registrations into a mailing list without explicit, logged consent is a GDPR/CAN-SPAM/PECR problem, not a bug. The package will happily do it; that is exactly why it needs a policy guardrail.
• Moderate: availability coupling. A Campaign Monitor outage or rate-limit response must never block a form submission or a user registration. Whether the addon degrades gracefully (fire-and-forget, queued, logged) is the single most important thing to verify and, if absent, to wrap.
• Low–moderate: release-note hygiene. v3.0.1's note ("fix blueprint layouts in v6") is a UI/CP correctness fix tied to Statamic 6 — reassuring evidence the addon tracks current Statamic, but it tells us nothing about the Campaign Monitor sync path, which is what we actually depend on.

Key questions

1. Which Statamic and Laravel majors are supported, and is the v3.x line the Statamic 6 line? What is our upgrade path when Statamic 7 lands?
2. Is this a maintained fork/successor of earlier Statamic–Campaign Monitor addons, and is there a migration path from them?
3. How does the addon behave when the CM API fails, times out, or rate-limits — does the form submission still succeed, and where is the failure surfaced?
4. Are subscriber writes queued or synchronous? Can we force them onto a queue so a slow ESP never degrades page response time?
5. Does it support double opt-in, and does it record or expose consent state/timestamp?
6. What happens on unsubscribe and on user deletion — is there any bidirectional reconciliation, or does CM drift from Statamic permanently?
7. Are custom fields auto-created in CM or must they pre-exist, and what are the per-list field limits?
8. Multisite: does it support per-site list mapping and per-site credentials?
9. Are API credentials and subscriber PII kept out of logs and out of version control?
10. Maintainer support posture and release cadence — is there paid support, or is GitHub the only channel?

Integration Approach

Stack fit

Fits a Statamic-on-Laravel application already using Statamic Forms and/or native user registration, with Campaign Monitor as the existing or chosen ESP. It does not fit if we are mid-migration off Campaign Monitor, if marketing owns the ESP contract and will not grant API keys to engineering, or if forms are rendered by a separate front end (Next.js, etc.) that bypasses Statamic's submission pipeline — in that case the Antlers tags and fieldtype are unusable and we would only be consuming the underlying API wrapper, which changes the buy-versus-build calculus.

Migration path

Greenfield: install, configure, map fields, ship. Brownfield with existing custom Campaign Monitor code: run both in parallel behind a config flag, route a single low-traffic form through the addon, compare the subscribers created in CM (fields populated, list correct, consent recorded) against the legacy path, then cut over form by form. There is no data migration — CM remains the system of record for subscribers; Statamic remains the system of record for users. Deliberately keep those two facts separate in the design doc, because conflating them is how teams end up with two half-truths about who is subscribed.

Compatibility

Confirm Statamic major (v6 implied by the 3.0.1 fix), PHP version, and Laravel major before committing. Check the Campaign Monitor account's plan tier for API access and custom field allowances. Verify the fieldtype renders correctly against our blueprints — this is precisely the area 3.0.1 patched, so test on a copy of a real blueprint, not a toy one. Pin the exact version; do not float.

Sequencing

1. Confirm Statamic/Laravel/PHP versions against the addon's support matrix (blocking).
2. Provision a separate Campaign Monitor test account or sandbox list — never validate against the production list.
3. Decide and document the consent model (opt-in vs double opt-in; whether registration auto-subscribes) before any configuration.
4. Prototype one form and one registration flow in staging; verify list membership, custom field mapping, and unsubscribe behaviour.
5. Force an API failure (bad key, blocked egress) and confirm the form still submits and the failure is observable.
6. Wrap the integration point if needed so the ESP is behind a thin internal interface — cheap now, invaluable if we swap ESPs in 18 months.
7. Roll out to one production form, monitor for two weeks, then expand.
8. Pin in composer.lock; record the consent decision and the version rationale in the dependency log.

Operational Impact

Maintenance

Low code maintenance, non-trivial policy maintenance. The addon itself needs only occasional version bumps alongside Statamic upgrades. The recurring work is ownership of the consent model, the field-mapping table (every new form field is a potential mapping gap), and periodic reconciliation between Statamic users and CM subscribers. Assign a named owner — in practice this lands on whoever owns marketing ops, with engineering on call for the plumbing. That ambiguity is the most common way this class of integration quietly rots.

Support

Two support surfaces. Upstream: MIT, small maintainer team, GitHub issues only — assume no SLA and no fast turnaround; keep the previous working version pinned for rollback. Downstream: the marketing team will treat "the newsletter signup is broken" as an engineering ticket regardless of whether the fault is Statamic, the addon, our config, or Campaign Monitor's API. Build a one-page runbook with the three checks (credentials valid, list ID correct, API reachable) so first-line triage does not require an engineer.

Scaling

Comfortable at typical CMS traffic; the constraint is Campaign Monitor's API rate limits, not the addon. Two things to verify: whether subscriber writes are queued (preferred — decouples form latency from ESP latency) and whether bulk operations (imports, backfills, reconciliation scripts) will trip rate limits. If we anticipate high-volume signup bursts — a launch, a campaign landing page — put the writes on a queue with retry/backoff and a dead-letter path before the traffic arrives, not after.

Failure modes

• Silent subscriber loss: CM API failures swallowed, forms still return success, marketing sees a smaller list than reality. Mitigation: log every failed sync to a queryable store, alert on failure rate, and surface a reconciliation count.
• Consent breach: registration auto-subscribes users who never opted in. Mitigation: explicit opt-in checkbox, consent stored in Statamic, and legal review before enabling registration sync.
• One-way drift: unsubscribes and deletions in CM are invisible to Statamic, and vice versa. Mitigation: define which system is authoritative per field and schedule reconciliation; accept that full bidirectionality is out of scope.
• Rate-limit cascade under load: mitigation as above — queue, backoff, circuit breaker.
• Credential leakage: API keys in a committed config file or in log output. Mitigation: environment variables only, log scrubbing reviewed during the prototype.
• Abandonment: a 3-star addon whose maintainer moves on. Mitigation: keep the integration behind our own thin interface so replacement is a contained task, not a rewrite.
• Upgrade breakage: a Statamic major lands before the addon catches up. Mitigation: pin, stage the Statamic upgrade, and treat the addon's Statamic-6 readiness as evidence it is actively tracked rather than guaranteed for 7.

Ramp-up

Low for anyone who knows Statamic — the concepts (blueprints, fieldtypes, Antlers) are native, and the addon adds configuration rather than new mental models. The ramp-up cost is elsewhere: a new engineer needs the consent decision, the field-mapping table, and the failure-handling runbook written down, or they will re-derive them under incident pressure. Write those three artifacts during the pilot; they take an afternoon and they are the difference between a boring integration and a recurring incident.