Weave Code
Api Bundle Laravel Package
sylius/api-bundle
Sylius API Bundle integrates API Platform with Sylius to expose e-commerce resources through a REST/JSON-LD API. It provides resource configuration, serialization, filtering, pagination, and OpenAPI documentation for building custom storefront or admin clients.
[READ-ONLY] Unified API for Sylius eCommerce.
Frequently asked questions about Api Bundle
- Is sylius/api-bundle a Laravel package I can install with Composer into a Laravel app?
- No. sylius/api-bundle is a Symfony bundle and a read-only subtree split of src/Sylius/Bundle/ApiBundle from the Sylius/Sylius monorepo. It assumes the Sylius resource registry, Doctrine ORM, the Symfony DI container, and API Platform, so it will not run inside a Laravel application. If your goal is to expose commerce data from Laravel, look at API Platform used directly or a Laravel-native stack such as Sanctum plus API Resources.
- How do I install sylius/api-bundle and what does it require?
- You install it with Composer into an existing Sylius application, not into a clean project, because the bundle depends on the Sylius platform services being present. After requiring the package you register the bundle in your kernel, ensure API Platform is configured, and confirm the bundle version matches the Sylius version your application is pinned to. The split repository is published per Sylius release, so the tag you install should mirror your monorepo version.
- How do I use Sylius API Bundle with a Laravel frontend or admin client?
- Run Sylius as an independent headless backend and let Laravel consume its REST/JSON-LD endpoints over HTTP as an external system. The Laravel app never installs this bundle; it only speaks to the versioned API contract, which keeps deploy cadence and upgrade paths separate. Treat the API surface as a contract you version and test, and keep cart, pricing, inventory, and order state ownership clearly on one side.
- Which Sylius and API Platform versions does this bundle support?
- The supported versions track Sylius releases, since the package is a subtree split published alongside the monorepo tags. Check the composer.json constraints on the tag you intend to use to confirm the API Platform and PHP requirements. Because the Sylius API direction has moved toward API Platform, the older REST-oriented surface has a narrower upgrade runway, so verify which API layer your pinned Sylius version actually ships.
- How does authentication and authorization work for the Sylius API?
- Authentication depends on the Sylius version and whether you are on the legacy REST surface or the API Platform layer, so confirm this before writing an estimate. Older setups commonly use token or OAuth-style flows, while API Platform integrations rely on Symfony security authenticators you configure yourself. Either way, plan authorization rules per resource operation and test them explicitly, since the contract is observable but not something you can steer from the client side.
- How do I add pagination and filtering to Sylius API responses?
- Pagination and filtering come from API Platform resource configuration, which this bundle extends for Sylius resources. You enable and tune them through resource attributes such as pagination items per page and filter declarations, including Sylius-specific filters where provided. Keep the chosen parameters part of your documented contract so Laravel or other clients do not break when configuration changes.
- How do I customize serialization and expose custom resources through the Sylius API?
- Serialization is driven by Symfony serializer groups and API Platform metadata, and the bundle exposes extensible configuration for registering additional resources. You typically declare a new resource, map it to an existing Sylius or Doctrine entity, and define its operations and normalization context. Changes belong in your application configuration rather than the vendor bundle, since the package itself is read-only.
- Why is the GitHub repository read-only and how do I contribute fixes?
- The repository is a read-only subtree split generated from the Sylius monorepo, so issues and pull requests are not accepted there. Patches must go upstream to Sylius/Sylius or into a fork of the full monorepo, and the split repository will pick them up when it is regenerated. That also means low star counts and dependent numbers here are publishing artifacts, not adoption signals.
- What are the production and maintenance risks of depending on sylius/api-bundle?
- The main risk is schedule and contract risk rather than runtime instability: you inherit an API surface you can observe but cannot steer, and patches route through the upstream monorepo or your own fork. There is also the upgrade question, since the REST bundle is the legacy layer relative to Sylius's API Platform direction. Decide up front who escalates contract breakage, particularly if you are not buying commercial Sylius support.
- How should I test a Laravel client against the Sylius API contract?
- Use contract testing against the OpenAPI documentation the API Platform layer generates, plus recorded or mocked responses for fast unit tests. Run a smaller suite of integration tests against a real Sylius instance for the operations you actually depend on, such as catalog reads and order queries. If you plan write paths like cart mutation, checkout, or payments, scope and test those as a separate phase with their own acceptance criteria.
Weaver
How can I help you explore Laravel packages today?