- How do I install bitbucket/client in a Laravel application?
- Run composer require bitbucket/client. There is no Laravel service provider, facade, or config publishing, so register a singleton binding in a service provider and feed credentials from config/services.php. Keep the SDK behind a small wrapper interface so the vendor surface stays confined.
- Is bitbucket/client compatible with Laravel 9, 10, and 11?
- It is a framework-agnostic PHP SDK, and the assessment reports compatibility with Laravel 9–11 on PHP 8.1+ and Guzzle 7. Always verify the exact composer.json constraints before pinning a version. It coexists with Laravel's HTTP client, but keep the two separate so the SDK boundary remains legible.
- How do I authenticate bitbucket/client against Bitbucket Cloud?
- The package supports OAuth 2.0 access tokens, app passwords, and repository access tokens, and it works with both Bitbucket Cloud and Server. Token refresh and credential storage are generally left to the caller. Decide on one auth model and centralize it in configuration rather than scattering credentials through the codebase.
- Can bitbucket/client manage repositories, pull requests, issues, and webhooks?
- Yes. The API objects map to repositories(), pullRequests(), issues(), webhooks(), and users(), which makes wrapping and mocking straightforward. Verify endpoint coverage for Pipelines, Code Insights, branch restrictions, and workspace-level endpoints against your exact pinned release.
- How should I structure bitbucket/client in a Laravel application?
- Bind it as a singleton in a service provider and wrap it behind a domain-level interface such as BitbucketRepositoryGateway. Do not call the SDK directly from controllers or queued jobs; expose intention-revealing methods instead. This keeps the vendor surface confined to one or two classes and makes testing easier.
- How do I test Laravel code that uses bitbucket/client?
- Mock the interface you wrote around the SDK, not the SDK itself. Laravel's Http::fake() applies to Laravel's HTTP client, not this Guzzle-based package. A thin wrapper makes fakes and unit tests straightforward without coupling tests to Bitbucket's API shape.
- What are the production risks of using bitbucket/client?
- The main risk is project maturity: roughly 103 stars, zero reported dependents, a thin maintainer bench, and no commercial support. Endpoint coverage may lag Bitbucket's surface, and pagination, 429 rate-limit handling, and webhook signature verification are typically your responsibility. Because it is MIT-licensed and small, document a fork-and-own contingency as an accepted risk.
- Does bitbucket/client handle pagination and rate limits automatically?
- The assessment notes incomplete handling of cursor-based pagination and 429 rate-limit semantics, so plan to implement retry and pagination logic in your wrapper. Check the exact release before relying on any built-in behavior. Injecting Guzzle middleware for retries and caching is the usual approach.
- What alternatives are there to bitbucket/client for Laravel?
- You can call the Bitbucket REST API with raw Guzzle or Laravel's HTTP client, use gentle/bitbucket-api (the project this package descends from), or rely on Atlassian tooling or shelling out to git and curl. This package is a low-effort replacement for raw Guzzle calls and a near drop-in for gentle/bitbucket-api, with namespace and auth-construction differences. Migrate endpoint-by-endpoint rather than in a big bang.
- Is bitbucket/client actively maintained and safe to depend on?
- The 2026-05-06 release date suggests the project is currently active, which materially improves the picture. However, the small community and thin maintainer bench mean you should check issue-tracker responsiveness and pin tagged releases. Document the fork-and-own risk as an accepted contingency rather than a surprise.