Weave Code
Candy Api Laravel Package
getcandy/candy-api
A Laravel package that adds a flexible REST API to GetCandy, exposing products, carts, orders, customers, and checkout through consistent JSON endpoints. Ideal for building headless storefronts and third-party integrations.
GetCandy v1 E-Commerce API
Frequently asked questions about Candy Api
- How do I install getcandy/candy-api in a Laravel application?
- Install it with composer require getcandy/candy-api, then run the package migrations, publish the config files, and seed any required base data such as channels, currencies, and taxonomies. The service provider registers the /api/v1/* routes automatically, and you authenticate consumers with Laravel Sanctum tokens. Mechanically the install is cheap; the real effort is understanding the config-driven class overrides and model resolution the package uses. Plan to pin your lockfile immediately after install, since the package has not been updated since 2021.
- Which Laravel and PHP versions does getcandy/candy-api support?
- The package targets Laravel 8 with PHP 8.0 or 8.1, backed by MySQL 8, Redis for cache and queues, and S3-compatible storage for media. Anything requiring Laravel 9 or 10 features, or PHP 8.2 and above, is out of scope unless you maintain a fork. Verify Postgres support yourself before committing, because MySQL is the assumed default. Because the project is archived, no new version constraints will be published for modern Laravel releases.
- Is getcandy/candy-api still maintained?
- No. The last release was 2021-09-22, and the upstream project was superseded by Lunar, which is a rewrite with a different data model and lunar_* tables. The community, issues, and documentation have all moved to Lunar, so candy-api receives no security patches or framework compatibility updates. If you adopt it, treat it as first-party source code that your team now owns and maintains.
- What endpoints does the GetCandy API expose?
- It exposes a consistent JSON REST surface under /api/v1/* covering products and variants, pricing and taxonomies, carts, checkout, orders, customers, payments, shipping, and discounts. Controllers return API resource transformed JSON, so responses are predictable enough to consume directly from a JavaScript storefront. All state lives in candy_* tables inside your own database rather than in an external service.
- How does authentication work with getcandy/candy-api?
- The API is secured with Laravel Sanctum personal access tokens, issued from your own Laravel application to customers or service clients. There is no external identity provider or OAuth server baked in, so token issuing, scopes, and revocation are your responsibility. This fits naturally if your storefront is a Sanctum-authenticated SPA or SSR app in the same codebase.
- Can I use getcandy/candy-api for a headless storefront like Nuxt or Next.js?
- Yes, that is the intended use case: the package was built to power headless storefronts and third-party integrations over JSON endpoints. You run Laravel as the commerce backend and consume /api/v1/* from Nuxt, Next, or any other client. Note that the admin experience is not included and comes via a companion Hub or Nova package, or you build your own. Budget for that surface explicitly, because it is not free out of the box.
- How do I handle security patches if I keep using getcandy/candy-api?
- Mirror the repository into a private VCS, add it as a path or VCS Composer repository, commit the lockfile, and forbid composer update outside a controlled branch. Then document your patch set so a future maintainer knows exactly which upstream fixes you have applied. This is the only realistic mitigation, because a CVE in Laravel 8 or a pinned dependency will have to be patched by you. Treat the dependency graph as frozen rather than floating.
- How hard is it to migrate from getcandy/candy-api to Lunar later?
- There is no supported importer, so products, variants, price tiers, customers, and order history must be ETL'd from candy_* tables into lunar_* tables by hand. Order history is the usual trap, because line-item and address shapes rarely map one-to-one between the two schemas. Plan the schema mapping as a deliverable rather than a task, and factor that cost into today's build-versus-buy decision. If you are choosing this as a twelve-month bridge to Lunar, say so up front so the migration budget is visible.
- Does getcandy/candy-api work with PostgreSQL?
- The documented target stack is MySQL 8, so treat Postgres support as unverified until you test the migrations and queries yourself. The package embeds a large domain schema, so any database-specific SQL or JSON column assumptions will surface quickly during a trial run. Verify this before committing, because changing database engines after you have loaded catalog and order data is expensive.
- What are the alternatives to getcandy/candy-api for a Laravel storefront?
- The direct successor is Lunar, which is a rewrite with a different data model and an actively maintained community. If you prefer not to own the commerce core at all, hosted options such as Shopify or Commercetools remove maintenance but add per-order fees and external data residency. Choosing candy-api only makes sense if you are already a Laravel shop that wants Eloquent-level access and full ownership of catalog, pricing, and checkout logic inside your own database.
Weaver
How can I help you explore Laravel packages today?