Laravel Mandrill Template Laravel Package

Product Decisions This Supports

This package is the Laravel-side integration for a third-party API that authenticates with an API key. Historically that key was almost certainly resolved from config/env at boot, which constrains what the product can do. The v2.0.1 addition — a support function that lets the API key be overwritten at runtime — is small in code and disproportionately relevant to product decisions:

• Multi-tenant and per-account credentials. Any feature where the API key belongs to a customer, workspace, or organization rather than to our deployment becomes viable. Previously this required forking the package or bypassing it with a custom client; now it is a supported path.
• Bring-your-own-key (BYO key) and enterprise procurement. Enterprise buyers frequently insist on using their own vendor account, their own contract, and their own key rather than ours. Runtime override is the technical prerequisite for that commercial model.
• Key rotation and incident response. Rotating a compromised key without a deploy or a config cache rebuild is now a product capability, not an ops fire drill. This affects our SLA claims and security questionnaire answers.
• Reseller / white-label / agency deployments. One codebase, many tenants, each with its own upstream account, becomes a configuration concern instead of a codebase-per-tenant concern.
• Environment and test isolation. Staging vs. production keys, per-test keys, and deterministic integration tests without mutating global config. This is a delivery-velocity win for engineering more than a customer-facing one.
• Runtime scoping for queued work. Because Laravel queue workers are long-lived, per-job key scoping (set on the job, reset after) is now expressible. This unlocks background jobs that act on behalf of different tenants in one worker pool.

What it does not decide: it doesn't change the vendor relationship, pricing, or rate-limit model, and it doesn't make the package suitable for cases where the vendor's own SDK is the better fit.

When to Consider This Package

Adopt when most of the following hold:

• We are a Laravel/PHP shop and want the vendor integration to feel native — service container binding, config publishing, facade or injected client, Laravel-native exceptions and HTTP layer.
• We need per-tenant, per-user, or per-request credentials, and the runtime override in 2.0.1 is the mechanism we'd use. If our keys are genuinely global and static, this feature is neutral and shouldn't be the deciding factor.
• We want the vendor's transport, retry, and error handling maintained by someone else rather than hand-rolling Guzzle calls.
• The vendor's API surface is stable enough that a thin community wrapper won't lag behind.

Look elsewhere — or budget for a thin in-house wrapper — when:

• We need guarantees the package doesn't make. A community package is not a support contract. If this integration is on a revenue-critical path and the vendor ships a first-party SDK, weigh the first-party SDK seriously even at the cost of Laravel idiom.
• The runtime override is global mutable state. Confirm from the source whether the support function sets a singleton/singleton-resolved client or is scoped. If it mutates a shared client instance, concurrent or queued usage in a single worker can leak one tenant's key into another's request. That is a security-shaped bug, not a style preference. Treat this as the primary diligence item.
• We need features beyond key handling — webhooks, pagination helpers, typed DTOs, async/batch — and the package is thin.
• We are not on a version the maintainer supports. We're on the 2.x line; a 2.0.x patch implies a recent 2.0.0 major. Confirm what broke in 2.0.0, whether we're already on it, and how active maintenance is.

Diligence checklist before adoption: read the support function's implementation and verify scoping/cleanup semantics; check test coverage for key handling; check the release cadence and open-issue responsiveness; pin the version and confirm the license fits our distribution.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk dependency upgrade that removes a real product constraint. The vendor integration we use for [capability] previously assumed one API key for the whole application, which quietly ruled out selling to customers who want to use their own vendor account and made key rotation a deployment event. The new release adds a supported way to set the key at runtime — that is the enabling piece for a bring-your-own-key tier, multi-tenant deployments, and same-day key rotation. The engineering cost is a version bump and a short review of how the key is scoped; there is no migration project. The risk to manage is correctness in long-running queue workers, which we can verify before rollout.

For engineering: v2.0.1 adds a support function allowing the API key to be overridden at runtime instead of being read once from config. Two things to confirm before we depend on it: (1) whether the override is scoped to a client instance/resolver binding or mutates a shared singleton — if global, we need explicit set/reset discipline and we must not rely on it inside long-lived queue workers without a reset in a finally; (2) whether the override is consulted on every request or cached on a resolved client, since a cached client would silently ignore later overrides. Pin to 2.0.1, add a regression test that sets a key, calls the client, and asserts the previous key is restored, and wrap tenant key resolution behind our own small factory rather than calling the support function throughout the codebase — that keeps the vendor package swappable and confines any future scoping fix to one place. Also confirm the 2.0.0 breaking-change list against our current usage before we bump the constraint.