Http Playback Laravel Package

Product Decisions This Supports

• Test architecture / CI reliability: It enables a hermetic test strategy for PHP services that call third-party APIs (payments, shipping, KYC, email, LLM providers). Record real responses once, commit them as fixtures, and replay them in CI — removing flaky external dependencies from the build.
• Build vs. buy (for test harnesses): The alternative is hand-rolling HTTP stubs or a custom faking layer. This package is a cheap "buy" that lets us defer building a bespoke mocking layer until real gaps appear.
• Roadmap enablement for integrations: Cuts the loop time on any feature that crosses a vendor boundary; engineers can develop and demo offline, and re-record fixtures when a vendor changes their contract, giving us a lightweight contract-drift signal.
• Cost and compliance decisions: Eliminates CI spend against paid sandbox tiers and the need for live vendor credentials in the build pipeline. It also forces an explicit decision on fixture governance — recordings frequently capture PII, tokens, or API keys, so we need a scrubbing convention and a repo policy before adoption.
• Support/diagnostics: Captured request/response pairs become reproducible bug artifacts — support can attach a recording instead of a screenshot and engineering can replay it locally.
• Platform-currency signal: v2.0 moves the package onto Guzzle 7 and adds PHP 8.x compatibility (dropping PHP 5.x). That aligns it with the HTTP client baseline of every Laravel version we would realistically run, which removes the single largest "will this even install" risk from the earlier assessment.
• Strategic weight: Still a tactical utility, not a platform dependency — negligible community footprint and a low release cadence. But the 2.0 line is the first version that is credible on a modern runtime, so the decision shifts from "adopt with a wrapper if it works" to "adopt with a wrapper, pinned to ^2.0."

When to Consider This Package

Consider it when:

• The application is PHP 8.x / Laravel and its outbound HTTP goes through PSR-18 or Guzzle 7, which the 2.0 release targets directly. Verify the app is not pinned to Guzzle 6 — v2.0 is a hard break on that axis.
• Integration tests are currently hitting live or sandbox endpoints, causing flakiness, latency, or per-run vendor costs.
• The team is small enough to absorb ownership of a low-activity library, and is willing to pin the version (^2.0), vendor or fork it, and wrap it behind an internal adapter.
• You need a reference implementation or a fast spike rather than a long-lived dependency.

Look elsewhere when:

• The stack is still on Guzzle 6 or PHP 7.x — v2.0 is explicitly incompatible, and the 1.x line is not a reasonable long-term landing spot.
• Maintenance depth matters — PHP 8 support is now confirmed, but the project still has a negligible contributor base and an irregular release cadence. Treat the 2.0 line as the ceiling of what we can expect, not a floor.
• Laravel-native tooling already suffices — Http::fake() covers the majority of feature-test needs; reach for playback only when real captured payloads (headers, pagination, error bodies) genuinely add fidelity.
• You need broader protocol coverage (SOAP, gRPC, streaming/SSE responses, WebSockets), parallel request handling, or first-class fixture matching and redaction rules.
• Procurement or compliance requires vendor SLAs, security review of a maintained project, or a contributor base large enough to survive the original author walking away.
• Mature alternatives fit the stack better: php-vcr, Guzzle's MockHandler, or Symfony HttpClient's mock responses.

How to Pitch It (Stakeholders)

For executives: Our integration-heavy features currently depend on live third-party APIs during testing, which makes builds flaky and occasionally billable. This MIT-licensed library lets us record those interactions once and replay them deterministically — faster, cheaper, more reliable CI, and a quicker loop for shipping API-dependent features. The new 2.0 release brings it onto current PHP 8 and Guzzle 7, so it installs cleanly on our stack. The cost to trial is on the order of a day of engineering, and it is trivially reversible.

For engineering: It's a small, PSR-18/Guzzle 7-compatible record-and-replay layer; fixtures live in the repo, so replay is deterministic and offline. v2.0 is a breaking release — Guzzle 7 is now required and PHP 5.x is dropped — which for us is a net positive but means we must confirm no service is still on Guzzle 6 before adopting. Caveats we still own deliberately: the project remains low-activity with a negligible contributor base, so we pin to ^2.0, wrap it behind an internal interface to keep it swappable, and establish a fixture-redaction rule so credentials and PII never reach version control. Treat it as a utility we control, not a dependency we rely on.