Log Subscriber Laravel Package

Product Decisions This Supports

• Debugging and observability of outbound HTTP traffic in legacy PHP services. This package exists to make third-party API calls visible in logs — request method, URI, headers, body, response status, and timing — which directly supports incident triage, support escalation, and "why did the checkout/quote/sync fail" investigations.
• Migration scoping, not greenfield adoption. Because the package is archived and Guzzle-4-era, the primary product decision it informs is how and when to retire it: identifying which services still depend on it, what those teams get from it today, and mapping that value onto Guzzle 6+ Middleware::log (or a PSR-3 middleware of your own).
• Build vs. buy vs. bundle. The capability is ~50 lines of middleware and ships natively in modern Guzzle. Any roadmap item phrased as "add HTTP request logging" should be closed as bundle from the framework, not built or adopted as a dependency.
• Support-cost and risk budgeting. An archived, 0-dependent, 43-star package is a liability in an audit: no security patches, no PHP-version compatibility guarantees, and an implicit lock on older Guzzle major versions. That's a line item in technical-debt planning and in any "are we upgrade-ready for PHP 8.x" conversation.
• Use cases it legitimately covers today: local/staging debugging of a partner API integration, one-off diagnostic logging in a legacy monolith that can't yet move Guzzle majors, and evidence-gathering during a vendor integration dispute ("here's the exact request we sent").
• What it does not support: customer-facing product features, differentiated capability, or anything on the growth roadmap. Treat it strictly as plumbing/ops hygiene.

When to Consider This Package

Consider it only if all of the following are true:

• The codebase is pinned to Guzzle 4 or 5 and upgrading the HTTP client is out of scope for the current quarter.
• You need request/response visibility now for a specific integration problem (partner API failures, timeouts, malformed payloads) and writing bespoke middleware isn't worth the review cycle.
• You already have a logging sink and a redaction policy for headers and bodies — this class of middleware will happily write Authorization tokens, API keys, and PII-laden payloads to disk.
• The dependency is confined to non-production-critical or internal-facing paths, or you accept archived-code risk with a compensating control (version pin, internal fork, or a scheduled removal ticket).

Look elsewhere — decisively — if any of these apply:

• You are on Guzzle 6+: use the built-in Middleware::log($logger, $formatter) from guzzlehttp/guzzle. It is maintained, tested against current PHP, and requires zero new dependencies. This is the correct answer for the overwhelming majority of teams.
• You need structured logs, sampling, correlation/trace IDs, or metrics. Native middleware plus a PSR-3 logger gets you there; this package gives you a formatted string and stops.
• You have compliance or audit obligations (SOC 2, PCI, GDPR). An archived package with no maintainer is a finding. Route to the maintained path.
• You need behavioral middleware — retries, circuit breaking, rate limiting. That's a different concern; look at maintained middleware or a gateway.
• 0 dependents and 43 stars means no community to absorb a bug fix. If you adopt it, you own it.

How to Pitch It (Stakeholders)

To executives (one paragraph): There's a small, archived open-source utility that logs outgoing HTTP calls — useful for debugging when a partner API or payment provider fails, but it's obsolete. Modern versions of our HTTP library include the same capability for free, and this package hasn't been maintained in years. Recommendation: don't add it anywhere new; where it already exists, replace it during the next routine upgrade. No budget or headcount impact — this is cleanup, not a project.

To engineering leadership: The capability is real and valuable; the package is not. It's Guzzle-4-era middleware with no maintainer, no security response, and no PHP-version guarantees, and it's been superseded by first-party Middleware::log since Guzzle 6. Two asks: (1) inventory where it's still referenced — low effort, likely small — and (2) fold replacement into existing Guzzle upgrade work rather than scheduling it separately. The one non-negotiable: whatever we use must redact Authorization headers and request bodies before they hit a log sink. That's a data-handling requirement, not a library feature.

To the requesting team: If you need to see what we're sending a third party this sprint, and you're on Guzzle 4/5, take it — pinned to an exact version, scoped to non-production or an internal path, with a removal ticket opened the same day. If you're on Guzzle 6+, here's the two-line native equivalent; use that instead and we'll close the request.