Laravel Mandrill Template Laravel Package

Getting Started

• Install the package with Composer and publish its config: php artisan vendor:publish --tag=<package>-config. The API key normally comes from config/<package>.php, which reads an env var (e.g. <PACKAGE>_API_KEY) — keep the secret in .env, never in the committed config.
• First places to look: the config file (defaults and base URL), the service provider (how the client is bound into the container), and the facade/helper the package exposes. If the README shows a Facade::call() style, the underlying client is a singleton resolved from config.
• First use case: set the key in .env, resolve the client in a controller or command, and make one read-only call. Confirm the key is actually being picked up before wiring anything else.
• New in v2.0.1: a support function now lets you overwrite the API key at runtime. If you are multi-tenant, running per-user credentials, or need different keys per environment inside one process, this is the entry point to evaluate first — check the package's source for the helper's exact name and signature rather than assuming the config key is still authoritative.

Implementation Patterns

• Configure once, override per request. Leave the config value as a sensible default/fallback and call the new support function at the start of the request or job when you need a tenant- or user-specific key. Treat config as the baseline, the support function as the override.
• Middleware for tenant context. In a multi-tenant app, resolve the tenant early (middleware or a tenancy bootstrapper) and set the key there, so controllers and services never think about credentials.
• Queued jobs. Set the key at the top of handle(), not in the constructor. Serialized job payloads carry your data, not the process state, so an override applied in the web request will not survive into the worker. Pass a tenant/user identifier on the job and resolve the key inside handle().
• Testing. The runtime override is usually cleaner than Config::set() in tests: set the key in setUp() or a test helper and let the client resolve normally. Assert on the outbound request (via the package's fake or Http::fake()) rather than on internal state.
• Service-layer wrapper. If you call the package from many places, wrap it in your own small service that applies the override and exposes only the methods you use. That isolates you from future signature changes and gives you one place to enforce key selection.
• Fallback logic. Only call the override when you actually have a key; otherwise let the config default apply. Guard against empty strings — passing '' or null may or may not reinstate the default depending on implementation.

Gotchas and Tips

• Resolution order matters. If the client is a container singleton, it may capture the key at construction. Set the override before the client is first resolved, or verify the implementation reads the key lazily on each request. A late override that silently does nothing is the most likely failure mode here.
• Long-running processes (Octane, Swoole, queue workers). Runtime overrides persist for the life of the worker. Always reset or re-set the key at the start of each request/job; otherwise tenant A's credentials leak into tenant B's call. Consider a finally block or a terminating callback that restores the configured default.
• Config caching. php artisan config:cache freezes config, and env() outside config files returns null. The runtime override sidesteps this for the key, but not for base URLs or other settings — keep those in config.
• Global helper collisions. The support function is likely a global function. If your app or another package defines the same name, you get a fatal redeclare. Check for collisions and prefer the underlying class/instance method where available.
• Don't log the key. Debug by printing a masked prefix/suffix of the effective key and confirming which source won (config vs. override). Add a short-lived assertion in a test rather than a dd() in production code.
• Extension points. If the support function doesn't cover your case (per-instance keys, multiple concurrent clients with different credentials), bind your own client instance in a scoped container binding or a factory rather than mutating a shared singleton.
• Version pinning. This is a patch release adding surface area; pin to ^2.0 and read the helper's implementation before relying on it — its exact semantics (set-only, resettable, per-instance vs. global) determine whether it is safe under concurrency.