Legacy Api Laravel Package

Product Decisions This Supports

• Decoupling the platform upgrade from the client release calendar. Bagisto Legacy API restores the pre-upgrade REST surface — catalog, search, cart/checkout, customer accounts, orders and invoices — so a core upgrade no longer forces an emergency rewrite of a shipped mobile app, an ERP/CRM/3PL integration, or an agency-maintained storefront. The decision it unlocks is when we upgrade, not whether we can.
• Framing the work as a migration, not an adoption. The correct PM stance is a time-boxed strangler bridge: keep legacy endpoints answering while a replacement API is built and consumers are moved over one at a time. Approval should ship with an owner, a contract-test artifact, and a sunset date in the same ticket — not as a routine composer require.
• Build vs. buy for compatibility glue. Reproducing legacy request/response conventions in-house is usually more expensive than a small MIT-licensed Laravel package. But with a single release (v1.0.0, November 2021), 5 stars, and zero dependents, the honest framing is buy, then vendor or fork and own internally. Price it as an internal maintenance line, not a vendor dependency.
• Containing the authentication blast radius. v1.0.0 moved JWT handling out of Bagisto core into this package and dropped the module service-provider dependency. That is useful product hygiene — the legacy token model becomes an explicit, scoped dependency rather than a core assumption — but it also means the security-sensitive surface now sits in code we must audit and own.
• Enabling coexistence rather than a cutover. Configurable route prefixes and middleware let legacy and current APIs run side by side, behind a feature flag and a separate rate limiter. That supports staged rollout with per-endpoint metrics and gives us a kill switch that does not touch the primary API.
• Use cases that justify the line item: stores with shipped mobile clients; integrations pinned to legacy payloads by third parties we cannot schedule; multi-storefront agencies that cannot coordinate client releases; and teams that need migration time measured in weeks or months rather than days.

When to Consider This Package

Adopt when:

• Bagisto is running in production and at least one live consumer parses the classic REST endpoints today.
• The upgrade is otherwise blocked, or would trigger an unscheduled client rewrite you cannot fund this quarter.
• You can pin an exact version, vendor or fork the code, and name an internal owner for patches and Bagisto-version compatibility.
• You need legacy and new routes to coexist via a configurable prefix and middleware, ideally behind a feature flag with its own rate limit and log channel.
• You have verified the three-version matrix — Bagisto core, Laravel/PHP runtime, JWT library constraint — against the 1.0.0 tag before committing engineering time.

Look elsewhere when:

• This is a greenfield Bagisto build with no legacy clients. Adding a second, unreleased API surface with no buyer is negative value.
• You require vendor-backed support, a published security policy, or a supported-version matrix. Assume community-only and internally owned.
• You need modern capabilities — GraphQL, webhooks, fine-grained scopes, a versioned public contract — that the legacy surface does not offer.
• You cannot absorb ongoing maintenance: JWT advisories, dependency bumps, and response drift fixes whenever Bagisto internals move.
• Legacy token auth is security-critical and nobody can commit to auditing issuance, expiry, and revocation in-house.
• There is no replacement API and no client migration plan on the roadmap. Adopting this without an exit just defers the problem and adds a surface you will struggle to remove later.

How to Pitch It (Stakeholders)

To executives: This package protects current revenue by keeping shipped mobile apps and partner integrations working while we upgrade Bagisto. Direct cost is low — MIT-licensed, narrow in scope, a Composer install rather than a build. The real decision is ownership: one release since 2021 and negligible adoption mean nobody upstream is contract-testing this against current Bagisto, so we should treat it as a time-boxed compatibility bridge — vendor or fork it, name an owner, set a sunset date tied to a published client-migration plan, and measure it with per-endpoint traffic until that date.

To engineering: This is a bridge, not a platform. Pin bagisto/legacy-api:1.0.0, give it its own route prefix, middleware group, guard, rate limiter, and log channel so it can never shadow or degrade the primary API. Enable only the endpoints that have a named consuming client. The first deliverable is not the integration — it is the golden-response contract suite, because backward compatibility fails silently in pagination envelopes, null handling, and error codes, and we will be running those fixtures on every Bagisto bump. Assume we own the code: a VCS fork so we can loosen the JWT constraint without waiting on upstream, and a runbook — secret rotation, per-endpoint kill switch, fixture update process — written the day we install.