Weave Code
Laravel Guzzle Laravel Package
astrotomic/laravel-guzzle
A lightweight Laravel integration for the Guzzle HTTP client. Configure Guzzle clients through Laravel's config and service container, resolve them via dependency injection, and make outbound HTTP requests with a familiar, framework-native setup.
Laravel wrapper for guzzlehttp/guzzle
Frequently asked questions about Laravel Guzzle
- What is astrotomic/laravel-guzzle and what does it actually do?
- It is a lightweight Laravel wrapper around the guzzlehttp/guzzle HTTP client. The package registers a service provider, ships a publishable config file, and exposes a configured Guzzle client instance through Laravel's service container. It is a convenience layer rather than a framework, so all real HTTP behavior still comes from Guzzle itself. That keeps the integration surface small and predictable.
- How do I install astrotomic/laravel-guzzle in a Laravel app?
- Install it with Composer using composer require astrotomic/laravel-guzzle. The service provider is auto-discovered, so no manual registration is normally needed. Publish the configuration file with the package's vendor:publish tag before customizing client options. Before rolling out, confirm that the Guzzle major version already resolved in your lock file matches what the package's composer.json permits, since that is the most likely source of conflicts.
- How do I configure Guzzle clients with this package?
- After publishing the config file, you define your client options there instead of scattering them across the codebase. That typically covers base URIs, timeouts, headers, and other Guzzle client constructor options per named client. Because configuration lives in Laravel's config system, it can be environment-driven and cached like any other config. Keep secrets in env variables rather than committing them to the config file.
- How do I resolve or inject the Guzzle client in Laravel?
- The package binds a configured client into Laravel's container, so you can type-hint it in a constructor or method and let the framework resolve it. A facade or alias is also provided for places where injection is awkward, such as quick scripts or legacy code. Prefer constructor injection in application services so the client stays swappable in tests. If you support multiple upstreams, resolve the specific named client rather than relying on the default binding.
- Does astrotomic/laravel-guzzle support Laravel 8, Laravel 9, and PHP 8.1?
- Version 2.4.0 added PHP 8.1 support and bumped the illuminate/support constraint, which widens rather than restricts viable environments. The package is described as compatible with Laravel 8/9-era applications on PHP 8.1. The important check is the actual resolved dependency set in your composer.lock, not the changelog wording. Run a dependency resolution against your pinned framework and PHP versions before trusting it in production.
- Should I use astrotomic/laravel-guzzle or Laravel's built-in Http facade?
- Laravel has shipped a first-party, Guzzle-backed Http client since 7.x, which covers much of the same ground with framework-level support, fakes, and retries. This package makes sense when you specifically want config-driven, injectable Guzzle clients or direct access to Guzzle features the Http facade hides. Adopting it also creates a second HTTP abstraction you must document and eventually maintain. Decide this strategically before writing any integration code, because standardizing on Http makes the rest moot.
- Can I use Guzzle middleware, retries, custom handlers, or async promises with this package?
- Because the package is a thin wrapper, the underlying client is still Guzzle, so Guzzle-level capabilities remain available where the client configuration allows them. That includes middleware stacks, custom handlers, connection pooling, and async promises for teams that need them. Confirm how your chosen config structure passes handler and middleware options through to the client constructor. If you depend heavily on these features, a short spike is worth more than reading the changelog.
- How do I test code that uses the laravel-guzzle client?
- Since clients are resolved from the Laravel container, the cleanest approach is to bind a fake or mock client in your test case and assert on the calls made. You can also point the client config at a Guzzle MockHandler through a custom handler stack to test responses without network access. Either way, inject the client rather than instantiating Guzzle directly so tests never touch a real upstream. Add at least one contract test against a real upstream outside the unit suite.
- Is astrotomic/laravel-guzzle actively maintained and safe for production?
- The technical assessment rates risk as low to moderate, with the main concerns being a very small maintainer pool and a release cadence driven largely by dependency updates. Version 2.4.0 is almost entirely CI and tooling changes, which is a healthy hygiene signal but also suggests limited feature investment. The package itself is small and stable, so the practical exposure is mostly transitive through Guzzle's major-version churn. Pin the version, watch for updates with Dependabot or Renovate, and keep an exit path in mind.
- How do I migrate existing new GuzzleHttp\Client() calls to astrotomic/laravel-guzzle?
- Start by inventorying every place your code constructs a GuzzleHttp\Client directly and noting the options each one uses. Move those options into the package config as named clients, resolve them from the container, and delete the duplicated configuration. Do this on a non-production branch and run your existing test suite plus one contract test against a real upstream. Roll out to a single service or outbound integration first, and document when to use this client versus the Http facade so the codebase does not drift into two idioms.
Weaver
How can I help you explore Laravel packages today?