Campaign Monitor Bundle Laravel Package

Product Decisions This Supports

• Build-vs-wrap for Campaign Monitor integration. This package only answers a narrow question: should we write our own Symfony container wiring for the official Campaign Monitor SDK, or reuse someone else's? It does not inform ESP selection, email architecture, or campaign strategy. For a Laravel product, the answer collapses quickly — you can't consume a Symfony bundle idiomatically, so the real decision is "adopt the underlying campaignmonitor/createsend-php SDK and wrap it ourselves."
• ESP ecosystem-health signal. Four stars, zero dependents, and a 0.14 score are themselves a data point. When the only PHP glue between a product and an ESP is an abandoned Symfony bundle, treat that as evidence that Campaign Monitor's PHP community is thin. Fold that into the vendor lock-in and long-term maintenance calculus, not just the integration ticket.
• Roadmap scoping for list/subscriber/campaign features. If the roadmap includes newsletter subscriber sync, list management, or campaign triggering via Campaign Monitor, this package represents the "minimal viable wiring" reference. A PM can scope the feature as "configure the SDK, expose a gateway, queue writes" rather than "build an API client" — the bundle's config keys and service definitions are a free spec for what fields and services the integration needs.
• Maintenance-burden forecasting. With near-zero adoption, the honest PM framing is not "free dependency" but "we own this code the moment we use it." Budget a fork/maintenance line item, or better, budget a thin internal wrapper over the SDK — which is what the bundle would have been anyway, minus a layer we don't control.
• Reference implementation for the gateway design. Even if unadopted, it tells you what the minimum viable integration looks like: credentials in config, a singleton client, thin access to lists/subscribers/campaigns. That informs how much scope to give the integration work versus feature work.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony — this is a bundle, not a Laravel package. It will not auto-discover, publish config, or register a service provider in Laravel, and there is no bundle kernel to load it.
• Campaign Monitor is already the committed ESP.
• You want container-managed credentials and pre-wired services rather than registering createsend-php yourself.
• You accept that you are effectively vendor-forking MIT-licensed code with no community support, and you have a named owner for updates, PHP/Symfony upgrades, and secret management.

Look elsewhere when:

• You're on Laravel. This is the primary disqualifier. Use the SDK directly and expose it through a ServiceProvider and a CampaignMonitorGateway interface; or evaluate Laravel-native multi-provider packages such as spatie/laravel-newsletter if Campaign Monitor is one of several ESPs under consideration.
• You need active maintenance, security responsiveness, or version currency. Near-zero adoption means no triage, no security channel, and likely stale Symfony/PHP Composer constraints that will conflict with modern stacks.
• A direct SDK dependency is sufficient. For a handful of API calls, the extra abstraction layer buys nothing you can't write in an afternoon — and you own it either way.
• You need production-grade concerns the bundle doesn't cover: rate-limit backoff, retry/idempotency, queueing for bulk syncs, webhook ingestion for bounces/unsubscribes, or PII/credential handling for GDPR/CCPA.
• You're evaluating a long-lived, high-traffic integration where upgrade paths and dependency risk outweigh saving a day of wiring.

How to Pitch It (Stakeholders)

For executives: This is a small, low-adoption open-source wrapper that connects Symfony apps to Campaign Monitor's email platform. It is not a strategic asset. The license is MIT, so there's no vendor cost, but there's also no community, no support, and no guarantee it works with current PHP or Symfony versions — and for our Laravel stack it isn't directly usable at all. The decisions that actually matter are whether Campaign Monitor is the right ESP and whether we're willing to own the integration code. Recommend: do not adopt as a dependency; treat it as a reference and budget a small, internally owned integration.

For engineering: It's a thin Symfony DI wrapper over the official campaignmonitor/createsend-php SDK — configuration for API key/client ID plus service definitions. It adds no meaningful API abstraction, no webhooks, no retries, no queueing. In Laravel, install the SDK directly, bind a configured client singleton in a ServiceProvider, put credentials in config/services.php and .env, wrap calls behind a gateway interface for testability, and queue subscriber/campaign writes to isolate API latency and rate limits. Read the bundle's Configuration.php and services.* files as a free spec for the config keys, then close the ticket. Plan to pin the SDK version and own the wrapper's fate, including PHP upgrades and credential rotation.