Candy Api Laravel Package

Product Decisions This Supports

• Build vs. buy for the commerce backend. candy-api is a ready-made headless commerce API layer (catalog, variants, collections, carts, checkout, orders, customers, shipping, tax, discounts, payments, media) on Laravel. The decision it informs is whether to spend 3–6 engineer-months building domain models, pricing logic, cart/order state machines, and API contracts, or to start from an Apache-2.0 codebase you can fork and own.
• Time-to-market / MVP scoping. For a D2C storefront, internal ordering tool, or marketplace pilot, it compresses the critical path: your team builds the storefront and the differentiators (merchandising, pricing rules, fulfillment integrations) instead of the commodity core.
• Architecture: API-first / headless. It pushes the roadmap toward a decoupled frontend (Next.js, Nuxt, mobile) consuming JSON:API, which is a durable decision affecting hiring, hosting, and CDN strategy — not just a library choice.
• Feature roadmap coverage. Use its endpoint surface as a checklist for "what's table stakes vs. our differentiation." Anything it already does natively (cart merging, discounts, tax classes, order statuses) is scope you can strike from the roadmap or defer.
• Platform lifecycle / tech-debt planning. Last release was September 2021 and GetCandy v1 was superseded by Lunar. This package forces an explicit decision: adopt as a short-cycle accelerator with a documented exit/upgrade path, or not at all. That's a roadmap risk item, not a footnote.
• Lock-in and licensing posture. Apache-2.0, self-hosted, no per-order or GMV fees. This supports a "own our data and margin" positioning versus Shopify Plus/Magento SaaS economics — relevant to pricing-model and unit-economics decisions.
• Build-vs-integrate for adjacent capabilities. Payments, shipping rates, and tax can be integrated rather than invented, because the API exposes extension points — this shapes vendor selection (Stripe, carriers, tax engines) and the integration roadmap.
• Team and hiring plan. Choosing a PHP/Laravel commerce core constrains hiring to Laravel engineers and narrows the candidate pool versus Node/TypeScript commerce stacks; it also dictates the skills you must retain for security patching once you fork.

When to Consider This Package

Consider it when:

• Your team is already fluent in Laravel/PHP and Eloquent, and can read and modify framework-level code rather than only consume a REST API.
• You need a headless, self-hosted commerce backend and are willing to own the codebase — including security patching — after adoption.
• You are building an MVP, internal tool, or market test where proving the commercial model matters more than long-term platform durability.
• Your catalog and rules are moderately simple: physical goods, a handful of currencies/regions, standard discounts and shipping, no complex B2B price lists or subscription billing on day one.
• Data residency, margin control, or license cleanliness (Apache-2.0, no copyleft, no per-transaction fees) are decision drivers.
• You want a reference implementation to mine for domain modeling and API design, even if you ultimately build your own.

Look elsewhere when:

• You are starting greenfield in 2025+. GetCandy v1 is effectively legacy; the maintained successor is Lunar. Evaluate that first and treat candy-api as a migration source or case study.
• You require an actively patched dependency with CVEs addressed, current Laravel/PHP support, and a release cadence you can plan around. A 2021 last release means you inherit patch responsibility on day one.
• You have compliance obligations (PCI DSS scope, SOC 2, audited change management) that demand vendor support, SLAs, or a maintained security program.
• You need enterprise commerce depth: multi-warehouse inventory, complex tax determination, subscriptions, B2B account hierarchies and negotiated pricing, or high-volume performance guarantees.
• Your stack is not PHP, or your organization has standardized on Node/TypeScript or Python commerce tooling.
• You want managed hosting and vendor accountability rather than an owned fork.

How to Pitch It (Stakeholders)

For executives (one paragraph): candy-api is an open-source, Apache-2.0 headless commerce API built on Laravel — the backend half of an online store: products, carts, checkout, orders, customers, discounts, shipping, and tax. It can remove several months of backend engineering from a first launch and carries no license fees or per-order revenue share, which improves unit economics versus SaaS commerce platforms. The trade-off is maintenance: the project's last release was September 2021 and it has been superseded by Lunar, so adopting it means we own patching, upgrades, and security. Recommendation: use it as a time-boxed accelerator with a documented migration path to Lunar (or our own service), not as a ten-year platform commitment. Approve it for an MVP with a 12-month reassessment gate.

For engineering: Familiar stack — Eloquent models, migrations, Laravel conventions, JSON:API conventions for request/response shape. It's forkable and hospitable to extension (custom models, observers, API resources). Expect to: pin and audit PHP/Laravel versions, own dependency patching, write integration tests around checkout and pricing, and plan a Lunar migration once traffic and requirements stabilize. Budget for the fork-maintenance overhead explicitly — it is real and recurring, not a one-off.

For finance/legal: Apache-2.0 permits commercial use, modification, and redistribution with attribution and no copyleft obligation on our proprietary storefront. No licensing cost; total cost of ownership shifts from subscription fees to engineer time for maintenance and hosting.

Decision framing: Don't ask "is this good software?" Ask "is this the right ownership model for our commerce core?" If the answer to "who patches this in 18 months?" is a named person with budget, proceed. If it's "someone," choose the maintained successor or a supported vendor.