Weave Code
Shopify Api Laravel Package
shopify/shopify-api
Official Shopify API library for PHP. Build Shopify apps and integrations with REST and GraphQL Admin API support, OAuth, webhooks, session storage, and typed request/response helpers for modern PHP applications.
Shopify API Library for PHP
Frequently asked questions about Shopify Api
- Is shopify/shopify-api a Laravel package with a service provider and config file?
- No. shopify/shopify-api is Shopify's official framework-agnostic PHP SDK: it ships PSR-7/PSR-18 HTTP, PSR-16 cache and PSR-3 logging bindings, plus Context, Session, Rest, Graphql and webhook utilities, but there is no service provider, facade, or publishable config. In Laravel you write the glue yourself, typically container bindings in AppServiceProvider, a config/shopify.php, a session repository, and middleware that hydrates and clears Context per request.
- How do I install and configure shopify/shopify-api in a Laravel application?
- Run composer require shopify/shopify-api, then pin an exact version rather than a caret range so a future API-version bump cannot surprise you. Create config/shopify.php for the API key, secret, scopes, app URL and an explicitly pinned Admin API version, bind the SDK's Context and clients in a service provider, and add the OAuth install and callback routes plus a webhook controller. Plan on a thin adapter layer instead of calling Shopify\Clients classes directly from controllers and jobs.
- Does shopify/shopify-api support both the REST and GraphQL Admin APIs?
- Yes. The library provides both a REST Admin API client and a GraphQL Admin API client, along with typed request and response helpers built on the same auth and session machinery. The two APIs have different quota semantics, since REST uses a leaky bucket while GraphQL uses calculated query cost, so your backoff and retry strategy has to branch per surface. Most new Shopify apps should default to GraphQL and treat REST as legacy.
- How do I implement the Shopify OAuth installation flow in Laravel with this SDK?
- The SDK includes OAuth helpers, but the routes, controllers, nonce and state storage, and post-install persistence are yours to build. A typical flow is an install route that redirects with the shop domain and scopes, a callback route that validates the HMAC and state, exchanges the code for an access token, then stores a Session keyed by shop. Expect roughly one to two sprints for a single engineer to reach a working merchant install, before write-path hardening.
- How should I store Shopify sessions and access tokens in a Laravel app?
- Implement the SDK's session storage interface and back it with an Eloquent model over a shopify_sessions table keyed by shop domain, or with Redis if you prefer. Persist the access token, granted scopes and shop metadata, and load the session into the SDK's Context at the start of each request or job. For multi-tenant apps this quickly becomes a distributed problem, because throttling and session state must be shared across every worker and server.
- How do I verify and handle Shopify webhooks in Laravel using shopify/shopify-api?
- Register a route, exclude it from CSRF protection, and read the raw request body before any middleware mutates it. Verify the X-Shopify-Hmac-Sha256 header with the app secret using the SDK's webhook utilities, return 200 immediately, and dispatch the real work onto a queue. Register webhook topics through the Admin API during install so subscriptions stay in sync across shops.
- Does shopify/shopify-api work with Laravel Octane and Horizon queue workers?
- Not out of the box. The SDK's Context object is process-global, so under Octane it leaks across requests and in Horizon workers it leaks across jobs unless you explicitly reset or rehydrate it per unit of work. Add middleware that sets and tears down Context around every request, plus a job middleware or base job class doing the same for queued work. This is the most common source of cross-tenant bugs with this library.
- How do I handle Shopify rate limits and retries across multiple Laravel workers?
- Shopify enforces per-shop limits, so a shared throttle ledger in Redis is required once you run more than one worker or server. REST calls consume a leaky-bucket allowance while GraphQL calls consume calculated cost, so backoff, concurrency and retry budgets must be tuned per API surface. Keep that logic inside your adapter so a future library swap never touches individual call sites.
- The shopify/shopify-api repository is archived. Is it still safe to use in production?
- Archived means no upstream security patches, no compatibility work for new Shopify API versions, and effectively no peer-reviewed usage signal to rely on. Shopify ships a new API version quarterly and sunsets old ones on a fixed calendar, so an archived SDK drifts out of support on a predictable date. It remains usable for a scoped build if you pin an exact commit, vendor a fork under your namespace, record it in your SBOM, and first confirm the archive is not a supersession you should adopt instead.
- How do I migrate off shopify/shopify-api or swap it for a maintained alternative later?
- Define a ShopifyGateway interface owned by your domain and confine the SDK to a single adapter class, so no call site references Shopify\Clients directly. That seam turns a future swap into a one-class change and lets you run both adapters behind a feature flag, cutting over endpoint by endpoint. Combined with a pinned commit, an ADR recording the chosen API version, and the quarterly deprecation calendar on your roadmap, it makes adoption an adopt-with-exit decision rather than lock-in.
Weaver
How can I help you explore Laravel packages today?