- What does the orchestra/http package do?
- It is the HTTP component of the Orchestra Platform, providing reusable helpers for working with HTTP requests, responses, and testing inside Laravel applications. It extends Laravel's native request and response handling with Orchestra conventions rather than replacing it. It ships as a standard Laravel service-provider dependency, so it fits a conventional application structure without new infrastructure.
- How do I install orchestra/http with Composer?
- Install it with composer require orchestra/http and let Laravel package discovery register the service provider. For Laravel 8 applications use the ^6.0 constraint. Check the resolved constraint against your PHP and Laravel versions before running composer update in a shared codebase.
- Does orchestra/http v6.0.0 support Laravel 8?
- Yes. The only documented change in v6.0.0 is added support for Laravel Framework v8, which is why it shipped as a major version bump. Treat that as the declared baseline and confirm forward compatibility with Laravel 9 or later yourself, because the release notes say nothing about it.
- Will orchestra/http v6.0.0 work on Laravel 6 or 7?
- It may be uninstallable on Laravel 6 or 7 due to Composer platform constraints, or installable but untested against those framework internals. The maintainers published only a one-line note, so it is unclear whether older support was dropped or simply left untested. Pin to the highest v5.x release if you must stay on Laravel 6 or 7.
- What PHP version does orchestra/http v6.0.0 require?
- The available documentation does not state a minimum PHP version explicitly. Laravel 8 itself requires PHP 7.3 or higher, so expect ^7.3 as the practical floor for v6.0.0. Confirm the platform constraint in the package's composer.json before upgrading a fleet that still runs PHP 7.2.
- Do I need to register a service provider or publish config for orchestra/http?
- It follows the standard Laravel service-provider pattern, so package discovery handles registration in a normal application. Whether you need to publish config or migration stubs depends on what the package ships. If you do publish them, diff the new stubs against your committed copies after upgrading, since that diff is where silent behavioral drift usually appears.
- Is orchestra/http a replacement for Guzzle or Laravel's HTTP client?
- No. It is a set of HTTP utilities layered on Laravel's own request and response handling, not a general-purpose outbound HTTP client. Use Laravel's HTTP client or Guzzle for external API calls and orchestra/http for request, response, and testing helpers within Orchestra-style projects.
- How do I test HTTP requests and responses with orchestra/http?
- The package provides helpers intended for HTTP testing across Orchestra projects, so you can assert against requests and responses without duplicating boilerplate in every test. Run your existing suite after upgrading, because Laravel 8 changed internals such as namespaced model factories and pagination views that can affect assertions. Add manual checks of the package's user-facing surfaces as a backstop.
- Is orchestra/http actively maintained, and is there a v5.x branch for older Laravel versions?
- There is no published statement about a maintained v5.x LTS branch or how long it would receive security patches, so ask the maintainer directly if you depend on Laravel 6 or 7. The v6.0.0 release note is a single line, which is a documentation gap rather than proof of abandonment. Review the repository's branch list and release history before committing to it as a long-lived dependency.
- How should I upgrade from orchestra/http v5 to v6?
- Run it as a bounded spike rather than a broad rollout: bump the constraint to ^6.0 in a disposable branch, run composer update for the package alone, republish any shipped config or migration stubs, and diff them against what is committed. Then run the full test suite and manually exercise the package's user-facing surfaces. Do not treat it as a drop-in patch upgrade on a Laravel 6 or 7 codebase.