Api Bundle Laravel Package

Product Decisions This Supports

• Headless / composable commerce bet. This bundle is the vendor-supported HTTP surface for a Sylius store — catalog, cart, checkout, orders, customers, promotions. It turns "decouple the storefront from the PHP monolith" from a bespoke API program into a configuration exercise. The PM decision it enables: do we ship a Next.js/Nuxt/native client against a supported contract, or do we fund an API team?
• Channel expansion roadmap. Every new client (mobile app, marketplace connector, B2B portal, in-store POS) is an integration project. A stable resource-oriented API converts that into "one client build per channel" instead of "one backend per channel" — a different cost curve on the roadmap and a different hiring plan.
• Build vs. buy on the integration layer. The counterfactual is hand-rolled controllers, serializers, pagination, filtering, and auth for every exposed entity. That work is undifferentiated, high-churn, and breaks on core upgrades. Adopting the vendor bundle converts it into configuration and inherits upgrade compatibility — the PM-relevant trade is less control, materially less owned surface area.
• Partner and back-office integration scope. ERP, PIM, 3PL, and accounting syncs need read and often write access to catalog and order data. Standardized endpoints shrink scoping per integration and make third-party vendors' existing Sylius connectors viable — which can compress a procurement cycle.
• Architecture constraint as strategy. Choosing this signals the domain model is accessed through a contract, not server-rendered templates. That constrains future feature design in a useful way: new capabilities must be API-expressible first. PMs should price in that constraint deliberately, because it will be felt at the next roadmap planning cycle.

Diligence caveat — read this before quoting the metrics. The raw signals on this artifact (5 stars, 0 dependents, score 0.145) are a false negative. This is a read-only subtree split published out of the Sylius/Sylius monorepo; real usage, issues, and releases live upstream. Judge adoption by Sylius install base and your own version pin, not by this repository's counters. And confirm the framework mismatch early: despite being filed among PHP packages, this is a Symfony bundle with no Laravel install path — it is only relevant if the commerce backend is Sylius.

When to Consider This Package

Adopt when:

• You are already running Sylius (or have committed to it) and need a programmatic interface to the store. This is the single hard prerequisite.
• The requirement is read-heavy plus standard checkout writes against core resources — not a bespoke domain.
• You need a mobile app or JS storefront backend within a quarter, not a multi-quarter platform build.
• Your team is fluent in Symfony and API Platform; the bundle's configuration model is idiomatic Symfony, and debugging it without that fluency is expensive.
• You want the API to track core upgrades automatically rather than maintaining a fork.

Look elsewhere when:

• You are on Laravel or a custom PHP stack. There is no meaningful "install into Laravel" path — no bundle concept, no equivalent to Sylius' resource graph. The realistic architecture is Sylius as a headless commerce service consumed over HTTP from Laravel via Saloon/Guzzle + DTOs; in that shape the bundle is not a dependency of your Laravel app at all. The decision then is whether to run Sylius, not whether to install this package.
• You need a GraphQL-first contract — evaluate Sylius' GraphQL support separately rather than assuming REST parity.
• You need deeply custom entities, pricing logic, or workflow states exposed. The bundle serves the core model; heavy customization pushes you back toward custom endpoints and erodes the buy case.
• You require an independently versioned, SLA-backed public API with its own support contract. This split has no independent release cadence or issue tracker; support is tied to the parent project and your commercial relationship with Sylius.
• You are pre-revenue and single-channel. A server-rendered Sylius storefront is cheaper; adding an API layer before a second channel exists is speculative architecture.

How to Pitch It (Stakeholders)

To executives: We get a vendor-maintained API for our store instead of paying our team to build and perpetually maintain one. It is MIT-licensed with no per-seat or per-call cost, and because it ships from the same codebase as the platform it upgrades alongside it rather than drifting. The commercial payoff is time-to-market on every additional sales channel — mobile, marketplace, B2B portal — which becomes a client build rather than a backend build. Two risks to state plainly: the public counters on this repository (stars, dependents) are meaningless artifacts of a read-only split and should not be used to judge maturity; and adoption deepens our commitment to the Sylius/Symfony ecosystem, so it should be treated as a deliberate platform decision, not an isolated utility. If commerce becomes revenue-critical, price commercial Sylius support at the platform level.

To engineering: This is a thin, configuration-driven Symfony bundle over API Platform that exposes the existing domain resources — no parallel model, no bespoke serialization layer to own. It is a read-only split of the main Sylius repo, so contributions and bug reports go upstream; pin it in lock-step with your Sylius version (1.12.x → api-bundle 1.12.x on API Platform 2.7; 2.x → 2.x on API Platform 3/4) and track releases through the parent project. Because there is no Laravel path, the integration boundary is HTTP: treat Sylius as an external system with a versioned OpenAPI snapshot committed to the repo, a typed client on the Laravel side, and contract tests that fail CI on drift. Three things to validate in a spike before committing: coverage of our custom entities and workflows, whether our checkout customizations survive the standard write paths, and auth ownership (Sylius-issued JWT vs. federated identity). Sequence auth, caching, and error normalization ahead of the first write path — retrofitting them after checkout is wired in is where the schedule risk lives. Expect the API contract to constrain domain changes going forward — that is the point, but it should be a conscious trade, not a surprise.