Laravel Sendcloud Laravel Package

Technical Evaluation

Scope and positioning: overtrue/laravel-sendcloud 2.0.0 is a Laravel service-provider wrapper around the overtrue/sendcloud SDK — API bindings, explicitly not a Laravel Mail transport. The value is low-ceremony container wiring (auto-discovery, sendcloud alias, services.sendcloud config, facade) for direct SendCloud API calls. Confirm the business use case before adoption: if the requirement is "send transactional email via SendCloud," this package does not satisfy it.

Architecture fit:

• Follows the idiomatic Laravel provider + facade + config-file pattern; minimal boilerplate, familiar to any Laravel developer.
• Client is now resolved from the container, which fixes application/container isolation — a real improvement for multi-tenant apps and test suites that boot multiple app instances.
• Client construction stays transient; the facade caches its client until facade state is reset. Efficient, but config is effectively frozen at first resolution.
• No Mail/Notification transport means no drop-in replacement for existing mail flows; integration is code-level.

Integration feasibility: Package wiring itself is small. The real cost is the platform jump — the version floor, not the code, drives the effort estimate.

Technical risk:

• High — version floor. Requires PHP ^8.3 and Laravel ^13.30; Laravel 9–11 and all versions below 13.30 are unsupported. Any service on Laravel ≤12 cannot take 2.0.0 without a framework upgrade. This is a platform project disguised as a dependency bump.
• Medium — Octane/long-running workers. Octane compatibility is explicitly not claimed, and cached facades plus frozen config is exactly the failure shape in resident workers.
• Medium — silent behavioral change in the SDK. HTTPS default, redirects disabled by default, cross-origin and HTTPS-downgrade redirects hard-fail, configured credentials take precedence, and leading-slash paths now preserve /apiv2/. These fail at runtime, not at compile time.
• Medium — prebuilt multipart bodies are no longer safe; upload() or multipart options must be used instead.
• Medium — no live verification. CI is 13 Testbench integration tests / 36 assertions on mocked transport, PHP 8.3/8.4/8.5, lowest-secure-deps job, strict Composer validation and audit. Strong for wiring; it proves nothing about the live SendCloud contract.
• Low — security posture is a net positive: advisory blocking on, Guzzle floor 7.15.2+, verified merge commit and green CI.

Key questions:

1. What are the actual PHP/Laravel versions across our fleet, and is a Laravel 13.30 upgrade already funded? Which services are hard-blocked?
2. Is SendCloud used for email delivery or for shipping/parcel APIs? If email, this is the wrong dependency.
3. Do we run Octane/RoadRunner/Swoole anywhere this would be deployed?
4. Do we have custom Guzzle middleware, redirect handling, or hand-built multipart bodies on the current path?
5. Do we have a SendCloud sandbox account for a live smoke test that CI does not cover?
6. Who owns the lockstep upgrade of overtrue/sendcloud ^2.0 alongside this package?
7. Is 1.x still receiving security fixes while we plan the platform upgrade, and what is our rollback window?

Integration Approach

Stack fit: PHP 8.3–8.5, Laravel 13.30+, Composer 2 with advisory blocking enabled, Guzzle 7.15.2+. Fits a modern Laravel monolith or modular service. Integration is code-level — inject the client or use the facade and call SDK methods directly.

Migration path (two projects, not one):

1. Inventory — composer show across repos for laravel/framework, php, overtrue/laravel-sendcloud, overtrue/sendcloud, guzzlehttp/guzzle. Produce a blocked-services list; that list is the business case for the framework upgrade.
2. Platform upgrade — Laravel 13.30+ and PHP 8.3+ as a separately released, separately validated change.
3. Co-upgrade — overtrue/sendcloud ^2.0 and Guzzle 7.15.2+ in the same commit as overtrue/laravel-sendcloud ^2.0. Never mix 1.x package with 2.x SDK.
4. Remediation — audit custom middleware, redirect config, and multipart handling; replace prebuilt multipart bodies with upload()/multipart options.
5. Config review — verify services.sendcloud keys and env vars; confirm credential precedence now favors configured values and that no runtime override is silently shadowed.
6. Sandbox verification — exercise auth, /apiv2/ path handling, redirect behavior, and error responses against a real SendCloud test account.

Compatibility notes: pin ^2.0 on both package and SDK. Runtime config mutation does not propagate to existing or cached clients — per-tenant credential switching requires explicit facade/container reset, or a design that resolves a fresh client per tenant. If a service relies on redirects, they must remain same-origin and HTTPS-preserving or calls will fail.

Sequencing: framework upgrade → SDK + package co-upgrade → middleware/multipart remediation → sandbox verification → staged rollout (one non-critical service, then canary, then fleet). Keep the 1.x branch pinned and deployable until canary passes.

Operational Impact

Maintenance: Smaller surface than a Mail transport, but two coupled dependencies must move together, and advisory blocking means builds will fail on new CVEs in either. That is desirable but requires a named owner and an explicit patch SLA rather than ad-hoc firefighting.

Support: Single-maintainer OSS upstream, no vendor SLA, no LTS statement attached to this release. Plan for internal ownership or a maintained fork; SendCloud API-level escalations go to the vendor directly.

Scaling: Transient client per resolution — no shared connection pool across resolutions. Fine for typical volumes; high-throughput batch shipping jobs should resolve once per worker and reuse rather than resolving per call.

Failure modes to instrument:

• Config changed after first resolution is silently ignored.
• Octane/resident workers hold a cached facade with stale credentials.
• Any SendCloud-side redirect (CDN, region move) now hard-fails under the default no-redirect policy.
• Credential precedence change shadows previously working auth.
• Leading-slash paths retaining /apiv2/ alter request targets for code that assumed stripping.
• Prebuilt multipart bodies break without a compile-time signal.
• No live test coverage means regressions surface in production, not CI.

Ramp-up: Low for a Laravel developer — the provider/facade/config shape is idiomatic and immediately recognizable. Moderate for on-call, because the failure modes are client-lifetime and configuration-propagation issues that never reproduce locally. Add a startup assertion that the resolved client carries the expected base URI and credentials, and a runbook entry covering redirect and credential-precedence failures.

Recommendation: Adopt 2.0.0 only after the Laravel 13.30 / PHP 8.3 platform upgrade is delivered. Until then, pin 1.x, confirm it is still receiving security fixes, and treat 2.0.0 as a milestone on the platform roadmap rather than a routine dependency update.