Verbose Error Http Client Laravel Package

Product Decisions This Supports

• Build vs. buy for outbound HTTP error handling. The package is a thin, single-purpose wrapper that surfaces the full response body (and request context) when an outbound HTTP call fails, instead of the truncated "400 Bad Request" you get by default. That makes it a "buy" decision only because the build is ~50 lines; the real decision is whether to standardize on one implementation across services rather than let each team roll its own.
• Roadmap investment in third-party integration reliability. Any roadmap item that depends on external APIs (payments, shipping, KYC, partner feeds) benefits from faster diagnosis. If support tickets routinely start with "the integration is broken," this moves MTTR rather than preventing the outage — a complement to retries/circuit breakers, not a substitute.
• Support and on-call tooling. Verbose error payloads shorten the loop between a customer report and a root cause, which is measurable in escalation time and in how often an engineer has to reproduce a failed call manually.
• Observability/logging policy. Full response bodies are a double-edged sword: they aid debugging but expand what lands in logs and exception trackers (PII, tokens, customer data). Adopting this package forces an explicit decision about redaction and log retention — worth having anyway.
• Dependency-floor governance. Release 2.2.0 raises the Symfony dependency from 7.4.* to 8.x and ships it as a minor version bump on a 2.1.2 base. This is a good forcing function to decide how much freedom you give small third-party packages to dictate your framework baseline, and to check whether your own versioning trust assumptions hold.

When to Consider This Package

Consider it when:

• You have several Laravel services making outbound HTTP calls and want one consistent, readable failure format.
• Your team spends real time reconstructing failed third-party calls from logs that don't contain the response body.
• You are already on, or are actively moving to, the framework baseline required by Symfony 8.x — the 2.2.0 constraint is the gating factor, not the package itself.
• The package surface is small enough that your team could vendor or reimplement it if maintenance stalls. Low lock-in risk is part of the value.

Look elsewhere (or write your own) when:

• You are pinned to Symfony 7.4 or below, or an older PHP floor. 2.2.0 will not install. You would need to pin 2.1.x, which puts you on an unmaintained branch — verify with the maintainer whether 2.1.x still gets security fixes.
• Your responses carry sensitive or regulated data. Verbose bodies in exceptions propagate into logs, Sentry/Honeybadger, and error emails. Without a redaction layer, this can create a compliance problem larger than the debugging benefit.
• You need structured, machine-readable error telemetry. This package optimizes for human-readable verbosity; if you need spans, metrics, and typed error codes, you want middleware plus instrumentation, not a message formatter.
• High-volume failure paths. Serializing large bodies into exception messages gets expensive at scale; sample rather than blanket-enable.

How to Pitch It (Stakeholders)

One-liner for execs: A small, low-cost library that makes failed third-party API calls self-explanatory, shortening the time between "the integration is broken" and "here's exactly why."

Why now: The package just shipped 2.2.0, moving to Symfony 8.x. That upgrade is the only real decision in front of us — the library itself is narrow and inexpensive to adopt or replace.

What it buys us:

• Faster incident diagnosis on any feature that depends on an external API; fewer manual reproductions.
• A single standard error format across Laravel services, which simplifies support handoffs and on-call runbooks.
• Negligible lock-in: thin wrapper, easy to fork or inline if the maintainer goes quiet.

What to watch:

• Versioning risk. A minor release (2.1.2 → 2.2.0) raises a major framework dependency. We should not assume patch/minor releases are safe; pin explicitly and read changelogs for anything in our dependency tree that touches framework constraints.
• Maintenance concentration. This release's headline change came from a first-time contributor, and the package is maintained by a single agency. Treat it as "probably fine, don't depend on it critically" and keep a copy of the pattern in our own codebase as a fallback.
• Data exposure. Verbose error bodies can leak customer data into logs and error trackers. Adoption should ship with redaction rules and a logging review.

Recommendation: Approve for evaluation on one or two services once we confirm our Symfony/PHP baseline supports 8.x; treat the 2.1.x pin as a stopgap with a defined expiry, not a resting state.