Mailer Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the integration/payload layer. A small, focused Laravel package that owns how request payloads are constructed and transmitted is a candidate to adopt rather than maintain in-house. The v0.9.0 change (body instead of a bodyAsString header) is the kind of decision we would otherwise pay an engineer to make and defend internally — buying it means inheriting that judgment cheaply, but also inheriting its timing.
• Feature scoping for outbound integrations. The move from header-carried payloads to a request body is directionally the right call for anything customer-facing: headers are size-constrained (commonly ~8 KB), frequently logged verbatim by proxies, CDNs, and WAFs, and are a poor fit for structured payloads. This supports scoping integration work around body-based contracts and treating header-based transport as a legacy path we should not design new features onto.
• Roadmap timing and contractual commitments. At v0.9.0 the package is pre-1.0, which means the public API is explicitly not frozen. This is a gating input for any roadmap item that promises a stable external contract to customers or partners: we can ship internal-facing integrations now, but external-facing ones should wait for a 1.0 tag or be pinned and wrapped behind our own adapter.
• Risk register / dependency policy. The release is evidence that transport-level behavior can change between minor versions. That argues for a standing policy of version pinning plus a thin internal wrapper around the package's payload construction, so a future body-related change is a one-file edit rather than a cross-service migration.
• Cross-team coordination cost. Because this alters what the receiving side must parse, it is not a pure internal refactor. Any consumer of our requests — partner endpoints, internal services, mocks in test suites — must be updated in lockstep. This is a scheduling and communication cost that belongs in the plan, not in the estimate's fine print.

When to Consider This Package

Adopt it when:

• You are building within Laravel and want a payload/HTTP layer that follows framework conventions rather than a bespoke abstraction.
• Your consumers are under your control — internal services, first-party endpoints, or partners who can absorb a coordinated change.
• You can pin the dependency and wrap the payload-construction call site behind an internal interface, so version upgrades are localized.
• The integration is internal-facing or pre-GA, where the cost of a transport change is a sprint task rather than a customer communication.
• You want the body-based transport that v0.9.0 introduces, and would otherwise be writing that migration yourself.

Look elsewhere when:

• You need a stable, versioned public API with a support window or an SLA. Pre-1.0 semantics mean minor releases may change behavior, and v0.9.0 is a live example.
• You must support header-based consumers for the foreseeable future — for example, an existing partner ecosystem that parses bodyAsString and cannot change on your schedule. Check whether 0.9.0 retains a compatibility path before assuming a clean cutover.
• You have no ability to coordinate both sides of the wire, or you rely on intermediary infrastructure (WAF rules, API gateways, logging pipelines) that inspects headers and would need reconfiguration.
• You need observability, retry semantics, or delivery guarantees the package does not claim to provide. Nothing in this release speaks to those, so do not infer them.
• The engineering surface is trivially small for your use case — if you need only one request shape, a direct framework call may cost less than a dependency plus its upgrade cadence.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small Laravel package for handling outbound request payloads. The latest release (v0.9.0) moves the payload from an HTTP header into the request body — a correctness and security improvement, since headers are size-limited and are routinely captured in proxy and gateway logs. The important signal is timing: at v0.9.0 the package has not declared a stable API, so I recommend adopting it for internal integrations now, pinning the version, and holding any customer-facing commitment until 1.0. Cost is low and lock-in is contained by a thin internal wrapper; the real risk is coordination, not licensing or engineering effort.

For engineering: Treat v0.9.0 as a transport-contract change, not a refactor. The receiving side now reads the payload from body rather than a bodyAsString header, which means: confirm whether any backward-compatibility path exists before dropping header support; update all request fixtures, contract tests, and mocks; and audit proxies, gateways, and log pipelines for header-based assumptions in both directions. Pin the dependency, route payload construction through a single internal adapter so the next change is localized, and add a contract test that asserts the payload location explicitly — that test is what makes the next bump cheap.