Weave Code
Api Laravel Package
bigcommerce/api
A PHP client for the BigCommerce API with OAuth authentication and ready-made resources for catalog, orders, customers, carts, and store data. Simplifies building integrations and apps against BigCommerce REST endpoints.
Connect PHP applications with the Bigcommerce Platform
Frequently asked questions about Api
- How do I install bigcommerce/api in a Laravel application?
- Install it with composer require bigcommerce/api. The package requires PHP 8.1 or newer and depends on Guzzle 7, so it installs cleanly alongside modern Laravel versions. There is no publishable config or package auto-discovery, so you register and configure the client yourself in a service provider or a dedicated integration class.
- Is bigcommerce/api compatible with Laravel 10 and Laravel 11?
- Yes. The SDK depends on Guzzle 7, which matches Laravel's own HTTP client dependency, so Composer conflicts are unlikely on Laravel 9, 10, and 11. Current 3.x releases require PHP 8.1 or newer. Because the package is framework-agnostic, it declares no Laravel version constraints and you are responsible for wiring it into the container.
- What are the alternatives to bigcommerce/api for a Laravel project?
- For most teams bigcommerce/api is the canonical choice because it is the official, MIT-licensed SDK maintained by BigCommerce itself. Alternatives usually mean writing your own Guzzle wrapper around the REST endpoints or adopting a community Laravel-specific wrapper, which adds another maintenance dependency. A common middle ground is to use the official SDK behind thin repository or action classes so your application code stays testable and replaceable.
- How does authentication work with bigcommerce/api?
- The client accepts OAuth credentials such as client ID, client secret, access token, and store hash, and it also supports legacy API account tokens. The SDK only attaches the token to outgoing requests; it does not run the OAuth install flow, refresh tokens, or store credentials securely. You must implement token acquisition, encrypted storage, and refresh logic in your Laravel application.
- How do I support multiple BigCommerce stores in one Laravel app?
- The store hash and access token are per-client configuration, so create one client instance per store instead of registering a single global singleton. A manager or factory class resolved from the container and keyed by store works well. This also keeps tenant credentials isolated when queued jobs process work for different stores.
- Should I use the Bigcommerce\Api\V3 classes or the legacy Client?
- Use the Bigcommerce\Api\V3 classes, which are generated from BigCommerce's OpenAPI spec; the legacy Bigcommerce\Api\Client targets deprecated v2 endpoints. A lot of community sample code still shows the old v2 client, so be careful when copying examples. Since V3 classes are regenerated between minor releases, pin exact versions and treat upgrades as scheduled work.
- How do I handle pagination and rate limits with bigcommerce/api?
- The SDK returns response objects, so read the pagination metadata and loop through pages yourself, or write a small helper that follows the links. Rate limiting and retries are not automatic; add Guzzle middleware to the configured HTTP client to back off on 429 responses. In Laravel you can also dispatch calls as queued jobs with rate limiting to smooth out bursts.
- Does bigcommerce/api verify BigCommerce webhooks in Laravel?
- No. Webhook signature verification and idempotent processing are not handled by the package and must be implemented against the raw request body before any parsing. In Laravel, exclude the webhook route from CSRF protection and read the payload with $request->getContent(). Persist event IDs so retried deliveries are deduplicated.
- Which version of bigcommerce/api should I pin for CVE-2025-45769?
- Pin bigcommerce/api to 3.3.12, which relaxes firebase/php-jwt to ^7.0 and remediates CVE-2025-45769; earlier 3.3.x releases carry the vulnerability. Pinning the SDK alone is not enough, because a widened constraint can still resolve to JWT 6.x, so assert the locked JWT version in CI and fail below 7.x. If your own code calls JWT::encode or JWT::decode, review it for the 6-to-7 major changes.
- How do I test Laravel code that uses bigcommerce/api?
- Inject a Guzzle client with a MockHandler or a fake handler stack so tests never hit the real BigCommerce API. Wrap SDK calls in your own repository or action classes and assert both the outgoing request and the parsed response. Because the V3 classes are generated and can shift between minor releases, keep a small contract test suite that runs on every SDK upgrade.
Weaver
How can I help you explore Laravel packages today?