Api Caller Bundle Laravel Package

Product Decisions This Supports

• Framing outbound API visibility as a product capability, not plumbing. The bundle's real asset is the Web Debug Toolbar panel that captures every outgoing cURL request — URL, headers, payload, response, timing — alongside the rest of the request profile. For a PM, that reframes "which HTTP client" from a dependency choice into a decision about whether the team can see and diagnose third-party traffic without adding bespoke debugging each time. That capability decision is worth carrying forward even though the code is not.
• Build vs. buy for an internal integration layer. The package is a compact worked example of the "thin shared wrapper" pattern: one call interface (api_caller service with HttpGetJson, HttpPostJson, HttpPostJsonBody, HttpPutJson, HttpDeleteJson, HttpGetHtml), one place to enforce timeouts, SSL verification, user agent, and redirect policy. A PM can use it to argue for a single sanctioned HTTP client in the codebase instead of ad-hoc cURL per feature — with the caveat that in Laravel the equivalent lives in the Http facade plus Guzzle middleware and Telescope, not in this bundle.
• Roadmap sequencing for integration-heavy quarters. With a backlog of payments, shipping, CRM, and partner APIs, the marginal cost is small for the first integration and grows with each one. This package is evidence for funding shared integration infrastructure before the integration backlog, with request/response capture and timing as table-stakes requirements rather than nice-to-haves.
• Support and incident-response economics. "The partner API is failing" tickets are resolved faster when the app records exactly what was sent and what came back. That is a support-cost and SLA decision as much as an engineering one, and it is the argument most likely to win budget.
• Where it genuinely fits: legacy Symfony 2.x–3.x applications, internal back-office tools, admin panels, and developer-facing utilities — contexts where the consumer is the developer and an in-toolbar inspector is directly valuable. Small, stable integration surfaces with a known set of endpoints.
• Where it must not drive decisions: anything on Laravel. This is a Symfony 2 bundle built on HttpKernel, EventDispatcher, bundle registration, and the web profiler; none of that substrate exists in Laravel, so only the trivial cURL wrapper is portable and the debugging surface — the reason to care — is lost. PHP 5.3-era requirements, no dependents, and a last release in February 2018 also make it unsuitable as a candidate dependency on any modern stack. Treat it as a reference design and a migration input.

When to Consider This Package

Consider it (more realistically, consider its design) when:

• You are maintaining an existing Symfony 2.1–3.x application and want outbound-request visibility inside the Web Debug Toolbar without introducing a new HTTP abstraction.
• The team's debugging workflow already lives in the profiler and you want request/response capture next to query and route data.
• The integration surface is small, stable, and low-risk — internal services or non-critical partner calls where a stalled request is an inconvenience rather than an outage.
• You are writing requirements for a replacement and want a minimal, concrete feature checklist to benchmark against: one call API, full request and response capture, timing, and profiler surfacing.
• You are doing a fork-and-extract exercise and only need the ApiCaller service shape as a starting point — accepting that you now own maintenance of an abandoned package.

Look elsewhere when:

• You are on Laravel. This is the decisive disqualifier. There is no AppKernel, no Symfony bundle registration, and no web profiler to integrate with. Use Laravel's Http facade (Guzzle underneath) with middleware plus Telescope or a custom logger for capture and timing.
• You are on Symfony 4+, or any currently supported PHP version. The stated requirements are PHP 5.3 and Symfony >= 2.1; compatibility shims will cost more than the feature is worth.
• You need a maintained dependency with a security-response path. No release since 2018-02-08, 64 stars, zero dependents — effectively no community validation and no upgrade pressure.
• You need modern HTTP capabilities: PSR-18/PSR-7 interoperability, async or concurrent requests, middleware pipelines, retry with backoff, circuit breaking, connection pooling, or structured telemetry such as OpenTelemetry traces.
• Your debugging target is production or non-developer environments. A toolbar panel is a developer-machine feature; production needs structured logs, traces, and metrics.
• Alternatives to evaluate instead: Symfony HttpClient (with its built-in profiler data collector), Guzzle 7 with the Symfony bundle or custom middleware, HTTPlug, or — for Laravel — the Http facade plus Telescope. All maintained, all with better ecosystem support.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, MIT-licensed Symfony 2 add-on from LeaseWeb that wraps cURL API calls and surfaces every outbound request in the Symfony debug toolbar, so developers can see exactly what was sent to a third party and what came back. Its strategic value to us is not as a dependency: it is a Symfony bundle, not a Laravel package, it is tied to an end-of-life PHP and Symfony generation, it has had no release since 2018, and it has no downstream users. Its value is as a validated pattern — teams that can inspect outbound traffic resolve integration incidents faster and write fewer one-off debug paths. The recommendation is to fund that capability natively on our current stack (Laravel Http + Telescope, or Symfony HttpClient's profiler collector) rather than adopt this package. The cost is small, the support-ticket savings are real, and we avoid inheriting an unmaintained fork.

For engineering — three bullets:

• The idea is right; the artifact is not. The toolbar integration is the differentiator, and it is welded to Symfony's kernel, event dispatcher, and web profiler — none of which exist in Laravel. Only the thin cURL wrapper would port, and that is the least valuable part. Do not add it to composer.json.
• We already have the replacement on both stacks. Laravel's Http facade over Guzzle 7, with middleware for retry/timeout/logging and Telescope for request capture and timing, covers the feature set on a maintained foundation. On Symfony, HttpClient ships a profiler data collector that does the same. Neither requires a fork, a security-review exception, or a named maintainer.
• Use it as a checklist, not a dependency. Pull its feature set — a single call API, full request and response capture, timing, and profiler/toolbar surfacing — into the acceptance criteria for our shared integration client, and add what the package lacks: retry with backoff, PSR-18 compliance, async support, structured telemetry, and redaction of credentials and PII from captured bodies. If we must touch a legacy Symfony 2 app, isolate the bundle there, record it as migration debt with a named owner and a sunset date, and audit the SSL and logging defaults rather than trusting the 2013-era configuration.