- Is vin-sw/shopware-sdk a Laravel package?
- No. It is a framework-agnostic PHP SDK for the Shopware 6 Admin API and ships no service provider, config file, facade, container bindings, queue integration, or publishable assets. Any Laravel integration is code you write yourself as a thin internal wrapper package. The only known Laravel adapter, Shape-and-Shift/shopware-laravel-sdk, targets Laravel 8, which is end of life.
- How do I install vin-sw/shopware-sdk and what are the requirements?
- Install it with composer require vin-sw/shopware-sdk. The package is MIT licensed and requires PHP 7.4 or higher plus ext-curl, and it is built on top of Guzzle. There is no Laravel auto-discovery, so nothing is registered in your application until you wire it up yourself.
- Which Shopware 6 versions does this SDK support?
- Version mapping is explicit and is the most important compatibility lever: SDK 2.x targets Shopware 6.5 and above, with 2.2.0 adding compatibility for 6.6.10.0, while SDK 1.x targets Shopware 6.4. Shopware 6.4 is effectively out of support, so treat the 1.x line as a dead branch. You can point 1.x at a 6.5 shop, but you will miss newer schema and features.
- How do I authenticate against the Shopware 6 Admin API with this SDK?
- You create a grant type object, either PasswordGrantType, ClientCredentialsGrantType, or RefreshTokenGrantType, or build one dynamically with GrantType::createFromConfig. Then pass it with your shop URL to AdminAuthenticator and call fetchAccessToken(), which returns the access token. Finally you construct a Context from the shop URL and token, and every subsequent API call runs against that context.
- Does the SDK refresh or cache Shopware access tokens automatically?
- No. fetchAccessToken() just returns a token string, and the README explicitly tells you to persist it yourself. There is no refresh scheduler, no expiry-aware caching, and no lock to prevent thundering-herd re-authentication across queue workers. Token lifecycle management is a required piece of your own build, not something the SDK handles.
- How do I use this SDK for multiple shops in a Laravel application?
- The Context object is the unit of tenancy: one shop URL plus one token per context, and one client per context. The SDK provides no connection pool, tenant resolver, or connection manager, so you must build a context and token registry yourself. In Laravel, a singleton registry keyed by shop and resolved through the container is a common pattern, and each resolved context should carry its own cached token.
- Can I write data with this SDK, including Sync API and versioning?
- Yes. The Admin API coverage includes CRUD, Sync, User Config, Notification, Admin Search, and other services, so bulk mutations, sync operations, and version deletes are all in scope. Be aware that write paths carry most of the package's defect history, including a broken version-delete and a syncDeleted call that used the wrong HTTP client. If you only need read-only search, you avoid the riskiest surface.
- Does the SDK support webhooks, and how is webhook authentication handled?
- Yes. It covers webhook registration, webhook authentication, and receiver helpers, and it can return PSR-7 action-button responses. Incoming requests are verified with WebhookAuthenticator::authenticatePostRequest($shopSecret), which is security-critical code living in a small single-maintaintainer package. Review that code path directly before trusting it in production.
- How do I test code that uses vin-sw/shopware-sdk in Laravel?
- There are no Laravel testing helpers, fakes, or built-in test doubles, so you mock at the HTTP layer. The SDK is Guzzle based and its changelog references injecting the same HTTP client used by the repository, which makes middleware, retry hooks, and a Guzzle MockHandler feasible, but you must wire that yourself. Wrapping the SDK behind your own interface and faking that wrapper is usually the cheaper approach in application tests.
- What are the production risks and alternatives to vin-sw/shopware-sdk?
- The dominant risk is supply chain, not code quality: roughly 119 stars, zero Packagist dependents, a single maintainer with a personal email as the security contact, and no CVE process or security policy. Entity and collection classes are generated from Shopware's DAL schema, so every Shopware upgrade becomes an SDK upgrade dependency, and breaking-change cadence is loose, with 2.0.0 shipping without migration notes. The main alternative is calling the Admin API directly with your own Guzzle client, or forking the SDK and pinning a version you control.