Laravel Shopify Laravel Package

Product Decisions This Supports

• Build vs. buy for embedded Shopify apps: This package is the "auth + billing + webhooks + API session plumbing" layer you would otherwise spend 3–6 engineer-weeks rebuilding. The decision it most directly informs is whether to adopt a maintained fork of a deprecated-but-battle-tested package versus building OAuth/App Bridge handling in-house. For a Laravel shop, adoption is almost always the right call unless you have unusual multi-tenant or non-embedded requirements.
• Go-to-market timing on Shopify's expiring offline tokens (April 1, 2026 deadline for new public apps): The package's v27.x line ships expiring offline token support, migration commands (shopify-app:migrate-expiring-offline-tokens), and a proactive renewal command for dormant shops. This is a compliance-driven roadmap item — if you have an existing install with legacy non-expiring tokens, you now have a discrete, schedulable migration workstream with a one-way (irreversible) cutover. That belongs on the roadmap as its own milestone, not a bug fix.
• Platform risk assessment / dependency triage: The README itself recommends eventually replacing or forking gnikyt/basic-shopify-api for REST/Graph traffic. That is a known strategic liability — a PM should decide now whether to (a) accept it, (b) budget a client-layer abstraction so swapping the HTTP client later is cheap, or (c) fund a fork. The fact that OAuth/token logic is already decoupled from that dependency lowers the risk of the auth half, which is the expensive half.
• App store / monetization features: Screenshots of a "Billable" flow indicate subscription and charge handling are in scope. This supports decisions about whether you can ship a paid app on a Laravel stack without a billing vendor.
• Operational model for serverless / Vapor deployments: Queue-targeting flags on the token batch commands (--queue=, --connection=, dedicated worker config) signal that serverless and queued-worker topologies are supported. This informs infrastructure decisions and whether you can run on Vapor without custom cron plumbing — note the package deliberately does not auto-register schedules, so scheduling is your app's responsibility.
• Use-case fit: Best suited to embedded admin apps serving many merchant shops (the shops table and per-shop token storage imply multi-tenant). Poor fit for single-merchant storefront-only integrations.

When to Consider This Package

Consider it when all of the following hold:

• Your app is Laravel 8+ / PHP 8+ (v26 dropped older PHP/Laravel support — verify your floor against the latest major before committing).
• You are building a Shopify app — particularly an embedded admin app — and need OAuth, session tokens/App Bridge, per-shop token persistence, webhook registration, and billing charges.
• You are multi-tenant (many shops, one codebase) and want a proven shops/users schema rather than designing one.
• You are already on, or willing to migrate to, expiring offline tokens, or you accept a one-way migration from legacy tokens.
• You can tolerate a single-maintainer, spare-time project with community PRs — the maintainer states this explicitly.

Look elsewhere or plan to hedge when:

• You need REST/Graph API traffic to be on an actively maintained client. The package defers to gnikyt/basic-shopify-api, which the README flags as something you may want to replace or fork. Budget for that.
• You need SPA/Vue-first or headless patterns. The stated goals list "better support for SPA apps using VueJS" and Blade/Shopify auth improvements as unfinished — these are open intentions, not delivered features. Do not plan around them.
• You are not on Laravel or not on a supported PHP version.
• You need enterprise SLAs, vendor support, or a guaranteed upgrade path — MIT license, no vendor, dependents count reported as zero (treat as a weak ecosystem signal, not necessarily a red flag given the package's history and 498 stars).
• You require automatic, self-healing token maintenance. Renewal is opt-in via CLI + your own scheduler; dormant shops will lapse without you wiring it up.
• Your app is not a Shopify app. Obviously — but worth stating for stakeholder alignment.

How to Pitch It (Stakeholders)

To executives: This is an MIT-licensed Laravel package that gives us the standard Shopify app foundation — merchant install/OAuth, per-shop credential storage, webhooks, and billing — off the shelf, instead of us building and maintaining it. It is a maintained fork of the widely used original laravel-shopify package, which was deprecated; the community kept it alive and it is now being actively updated for Shopify's 2026 token requirements. That last point is the headline: Shopify is mandating expiring offline tokens for new public apps from April 2026, and this package already ships the migration tooling, including batch commands safe for serverless. Adopting it converts a compliance deadline into a scheduled, reversible-until-cutover migration rather than an emergency.

To engineering: It handles the parts nobody wants to write twice — OAuth code exchange, session-token exchange, refresh grants, token encryption, per-shop API client construction, and charge flows. You get artisan commands for migrating legacy tokens and proactively renewing near-expiry refresh tokens, plus queue/connection targeting for Vapor-style deployments. Two caveats to plan around: (1) the package intentionally does not register a scheduler, so renewal is our cron to own; (2) token refresh happens at API-client build time, so long-running jobs must either enable the pre-call refresh check or call refreshOfflineAccessTokenIfNeeded() per loop iteration. Also, keep APP_KEY stable — refresh tokens are encrypted with it, and rotation loses them.

Honest risk framing for both audiences: The API client dependency (gnikyt/basic-shopify-api) is the weak link and the maintainer says so. Our mitigation is to keep our Shopify business logic behind a thin internal service layer so the HTTP client is swappable. Maintenance is one primary maintainer working in spare time — acceptable for a package of this scope and maturity, but it argues for pinning versions and reviewing changelogs on upgrade rather than floating. Recommend adoption (buy, don't build), with a funded abstraction seam and a roadmap milestone for the token migration.