Laravel Sendcloud Laravel Package

Product Decisions This Supports

• Vendor integration choice: Confirms whether to standardize on SendCloud through a maintained Laravel binding rather than building a custom API wrapper.
• Platform upgrade planning: v2.0.0 requires PHP ^8.3 and Laravel ^13.30. This is a gating dependency for roadmap work on Laravel 9–12 or older PHP versions and should be scheduled as a platform upgrade, not a routine package bump.
• Security posture: The release hardens defaults around HTTPS, redirects, credential precedence, and Composer advisory blocking. This supports decisions to reduce custom HTTP/middleware code and rely on vetted SDK behavior.
• Feature scope clarity: The package provides SendCloud API bindings only — not a Laravel Mail transport. Product and engineering should not position it as a drop-in replacement for Laravel Mail or as a full multi-provider email abstraction.
• Operational model: Client construction is transient, but the facade caches its client until Laravel resets facade state. Runtime configuration changes do not update existing clients or cached facades. This affects multi-tenant, runtime-config, queue-worker, and long-running-process designs.
• Build vs. buy: Favorable when the team is already on SendCloud and wants container bindings, facade access, configuration integration, and tested request/auth/error behavior without maintaining its own wrapper.

When to Consider This Package

Consider adoption when:

• The application is on PHP 8.3+ and Laravel 13.30+, with a clear path to upgrade older services.
• SendCloud is already the selected email/API vendor and the team wants Laravel-native configuration, facade, and SDK bindings.
• The product needs direct SendCloud API access rather than a Laravel Mail transport.
• The team can accept API-bindings scope and will handle delivery observability, live SendCloud validation, and provider-specific workflows outside the package.
• The team does not depend on runtime configuration changes updating already-resolved or facade-cached clients.
• Custom middleware and multipart request construction can be reviewed and adjusted for the new redirect and request-body behavior.

Look elsewhere or defer when:

• The application remains on Laravel below 13.30 or PHP below 8.3.
• The product requires a Laravel Mail transport, multi-provider mail abstraction, or drop-in replacement for Mail::send.
• The architecture requires Octane compatibility guarantees; v2.0.0 does not claim Octane support.
• The product depends on per-request or per-tenant runtime reconfiguration of already-resolved clients.
• The team relies on prebuilt multipart bodies, permissive redirects, or custom middleware that may conflict with the hardened SDK defaults.
• The team needs live SendCloud integration assurance from the package’s own test suite; v2.0.0 tests use mocked transport and do not make live calls or use real credentials.

How to Pitch It (Stakeholders)

Executive summary: overtrue/laravel-sendcloud v2.0.0 is primarily a security and platform-baseline release, not a feature expansion. It narrows support to PHP 8.3+ and Laravel 13.30+, upgrades the SendCloud SDK to ^2.0, and hardens HTTPS, redirect, credential, and Composer security defaults. Adopt it only as part of a deliberate Laravel/PHP upgrade. It reduces the need to maintain custom SendCloud API plumbing, but it is not a Laravel Mail transport and does not claim Octane compatibility.

Engineering summary: Budget for the breaking upgrade first: PHP 8.3+, Laravel 13.30+, SDK ^2.0, Guzzle 7.15.2+, and review of custom middleware and multipart request construction. The package now reads configuration from the container when resolving the client, improving application/container isolation. However, clients remain transient while the facade caches its client, so runtime configuration changes will not propagate to existing clients or cached facades. Treat v2.0.0 as a hardened API binding with good container/facade/test coverage, not as a delivery transport or long-running-worker guarantee.