Laravel Http Client Logger Laravel Package

Product Decisions This Supports

• Observability for third-party integrations: Logs every outbound HTTP call made through Laravel's Http facade (request, response, status, timing, headers), turning "the payment provider is failing" into a specific request/response pair with a timestamp. Directly supports incident post-mortems, support escalation triage, and vendor SLA disputes.
• Build vs. buy: Replaces a bespoke logging middleware/trait that teams typically hand-roll and then abandon. Adoption cost is one Composer dependency plus a config publish — a clear "buy" against 2–5 days of internal engineering and ongoing upkeep.
• Roadmap signal — Laravel 13 readiness: v2.6.0 adds Laravel 13.x compatibility. If the platform roadmap includes a Laravel 13 upgrade, this dependency is no longer a blocker and does not need a fork or replacement. Factor it into the upgrade epic as "already green."
• Audit and compliance use cases: Outbound request logging supports evidence trails for data-sharing with third parties (what we sent, when, to whom), useful in vendor reviews and lightweight compliance narratives — provided redaction is configured.
• Product-scoping input: Cheap to enable per-environment, so it can be scoped as "on in staging and production, off in local," letting PMs promise faster integration debugging without new infrastructure spend.

When to Consider This Package

Adopt when:

• The application makes meaningful outbound HTTP calls (payments, CRM sync, shipping, auth providers, internal microservices) and failures currently surface only as generic 500s.
• The team is on Laravel 10–13 and comfortable with a package that hooks the framework's HTTP client.
• You want request-level traceability without standing up an APM vendor or a full OpenTelemetry pipeline.
• You need a per-environment toggle — the package's config-driven, enable/disable model fits staged rollouts.

Look elsewhere when:

• You need distributed tracing, span correlation, or latency dashboards across services — that is Sentry, Laravel Nightwatch, Telescope (dev-only), or OpenTelemetry territory, not this package.
• Outbound volume is very high and you intend to persist every call to a database or log channel; storage cost and write amplification need sizing before adoption.
• You require hardened PII/secret scrubbing with certification. The package offers configurable redaction, but validate it against your data-handling policy rather than assuming coverage.
• You need guaranteed vendor support, SLAs, or a security review cadence. This is a single-maintainer open-source package; treat it as community-supported and plan accordingly.
• You are not on Laravel, or you call APIs outside Laravel's HTTP client (raw cURL, SDKs with their own transport) — coverage would be partial and misleading.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk observability add-on for the integrations our product depends on. It records what we send to and receive from third-party APIs, which shortens incident resolution and gives us defensible evidence in vendor disputes. The v2.6.0 release confirms active maintenance and Laravel 13 compatibility, so it does not create upgrade debt. Cost is a Composer dependency and a small amount of log storage — no new infrastructure.

For engineering: Drop-in package that logs Laravel HTTP client traffic with configurable channels, redaction, and per-environment toggles. v2.6.0 is a compatibility-only release adding Laravel 13.x support — no breaking changes, no migration work beyond confirming the constraint resolves. Effort is roughly half a day: install, publish config, define redaction rules for auth headers and PII fields, decide retention. Two caveats to state plainly: it is single-maintainer with no SLA, and DB-backed logging needs volume sizing before production. Recommended path: enable in staging first, measure log volume for two weeks, then promote to production.