Shopware Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for Shopware connectivity. This is a buy (MIT, free) of an Admin API wrapper instead of an in-house one. The decision it unlocks is: do we spend 2–6 engineer-weeks writing auth, DAL criteria, sync, and webhook plumbing ourselves, or adopt this and spend that time on differentiating features?
• Headless/composable commerce roadmap. If we run Shopware 6 as the commerce backend and Laravel as the surrounding platform (admin tooling, ERP/PIM bridge, loyalty, CMS, ops dashboards), this SDK is the transport layer for that roadmap. It makes "connect Shopware to X" a sprint-sized feature rather than a quarter-sized one.
• Feature scope decisions. The feature list maps to concrete product capabilities we can commit to or defer: product/order/customer CRUD, bulk SyncService (feeds, price/stock pushes), NotificationService (admin-facing alerts from our app), UserConfigService (per-admin preferences), AdminSearchService (cross-entity search UI), and webhook-driven real-time sync (order state, inventory).
• App-store / integration-partner strategy. The webhook registration + authentication + action-button response classes (ported from Shopware core) mean we can ship a Shopware App rather than a plugin — a materially different distribution and lifecycle decision (no PHP plugin code inside the shop, no shop-side deploys).
• Version support policy. The 1.x → 6.4, 2.x → 6.5+ mapping forces an explicit decision on which Shopware versions we support and when we drop 6.4. That's a support-cost line item, not just a technical detail.
• Vendor-risk posture. With 119 stars, 0 dependents, and effectively a single maintainer, adoption is a dependency governance decision as much as a technical one. Plan for it: vendor/fork the package, or wrap it behind our own thin interface so it can be swapped for Shopware's official shopware/api-client (OpenAPI-generated) without touching product code.

When to Consider This Package

Adopt if:

• Your stack is PHP (7.4+) and you are integrating with Shopware 6.4+, and you specifically want DAL-style, object-oriented access (Criteria, EqualsFilter, RepositoryFactory::create(...)) so the code reads like Shopware core and your team's Shopware knowledge transfers directly.
• You need App capabilities — webhook registration/authentication, action-button responses, admin notifications — not just raw REST calls. This is the SDK's clearest differentiator.
• You are building a sidecar/integration service (order sync, ERP bridge, PIM push, ops console), i.e. moderate request volumes and human-scale CRUD, not millions of rows.
• You are willing to own the dependency: pin versions, fork or vendor if needed, and validate coverage with a time-boxed spike before committing.

Look elsewhere if:

• You need contractual support or a bus factor above one. There is no vendor, no SLA, and 0 dependents means little community pressure-testing.
• Your workload is bulk/high-throughput. Sync of large catalogs, high-frequency order ingestion, or anything where per-request abstraction overhead and memory behaviour matter — evaluate raw Admin API, Shopware's official shopware/api-client, or message-queue batching. (Release notes include a memory-exhaustion fix, which is a signal to load-test, not a disqualifier.)
• You are on Shopware 5, or on <6.4. Out of scope by design.
• You are not on PHP/Laravel, or you need a non-PHP service — use the platform API directly.
• You need deep plugin-level customisation inside the shop (storefront, theme, checkout logic). This SDK is Admin API only; Store API / storefront work is out of scope.
• You want first-party docs and support. Documentation here is README + examples/ + a companion AppExample repo. That's workable for a senior PHP dev, thin for a mixed-seniority team.

Gate before adoption (PM-owned checklist):

1. Spike: 3–5 days to prove auth (password + client-credentials), one CRUD flow, one sync batch, and one webhook round-trip against a staging 6.5/6.6 shop.
2. Confirm the 2.x line covers the entities we actually need — check src/Data/Entity against our integration surface, plus custom-entity support.
3. Decide the wrapping strategy up front: our own ShopwareGateway interface so the SDK is an implementation detail, not a leaky abstraction across the codebase.
4. Confirm license compliance (MIT — permissive, attribution only) and lock the version in composer.json.

How to Pitch It (Stakeholders)

For executives: We need to connect our Laravel platform to Shopware 6 for orders, catalogue, inventory and admin notifications. Building that connector ourselves means writing and then forever maintaining auth, query-building, bulk sync and webhook security — realistically several engineer-weeks plus ongoing upkeep for zero product differentiation. This MIT-licensed SDK packages that plumbing and is actively maintained (release cadence through 2026, tracked compatibility with Shopware 6.5/6.6). It is free and permissively licensed, so the financial exposure is engineering time, not licence cost. The real risk is concentration: it is a small, single-maintainer open-source project with minimal public adoption, so I am recommending a short validation spike and wrapping it behind our own interface — that caps the downside at a few days of work if we ever need to switch to Shopware's official client. Net: faster path to the integration roadmap, low switching cost, no vendor lock-in.

For engineering: vin-sw/shopware-sdk is a PHP 7.4+ / ext-curl SDK over the Shopware 6 Admin API, versioned to schema (2.x → 6.5+, 1.x → 6.4). The pitch is that it mirrors Shopware's own developer model: RepositoryFactory::create(ProductDefinition::ENTITY_NAME) + Criteria + filters + a Context (shop URL + access token), with entity/collection classes generated per DAL entity. Methods cover get/search/searchIds/create/update/delete/syncDeleted/createVersion/mergeVersion/deleteVersion/clone/schema, plus aggregate and partial loading via addFields. Auth supports password, client-credentials and refresh-token grants; tokens are designed to be persisted so we are not minting one per request. Concrete services exist for Info, Media, User, StateMachine, Sync, Notification, UserConfig and AdminSearch, with an AdminActionService fallback for endpoints without a concrete class. The part we cannot easily replicate cheaply is the App surface: webhook registration/authentication helpers and the action-button Response classes (EmptyResponse, ReloadDataResponse, OpenNewTabResponse, NotificationResponse, OpenModalResponse) ported from Shopware core — that is the strongest reason to take the dependency. Caveats to plan around: single maintainer with no dependents (pin the version, keep a fork path, and hide it behind our own gateway interface); README-and-examples-only docs; no Laravel service provider here (the linked adapter is third-party — we would register the client/context ourselves); and Admin API only, so Store API / storefront work is a separate decision. Compare against Shopware's official OpenAPI-generated shopware/api-client during the spike — if that covers webhooks and the DAL ergonomics we care about, it wins on vendor risk; if not, this SDK is the pragmatic choice.