Executive summary
- Shopify now publishes official, open source app packages for PHP and Python, both at version 1.0, covering request verification, token exchange, and Admin GraphQL calls.
- The previous shopify-api-php and shopify_python_api libraries are deprecated. They keep working but will receive no new features and no security fixes.
- Relevant to teams with internal PHP or Python capability who build custom apps or middleware against the Admin API.
What changed
Two packages reached general availability: shopify/shopify-app-php on Packagist and shopifyapp on PyPI. Both expose framework agnostic primitives rather than a full framework, so you compose only the pieces you need.
The primitives cover request verification for webhooks, App Home and App Bridge requests, app proxy requests, and Checkout, POS, Admin, Customer Account, and Flow extension requests. They also cover token exchange, including client credentials and refreshing exchanged access tokens, plus an Admin GraphQL client with automatic retry handling. They work with Laravel, Symfony, Django, FastAPI, or plain PHP and Python.
There is no app template for either language. You scaffold your own project and compose primitives. React Router remains Shopify's recommended path for most new public apps, and nothing changes for Node.js or Ruby.
Why it matters
Enterprise commerce teams rarely run on a single language. The ERP connector is often PHP, the data pipeline is often Python, and until now building against the Admin API in either meant community libraries or hand rolled HMAC verification. Hand rolled verification is where subtle security bugs live, because a comparison that is not constant time or a body that is parsed before it is verified will pass every functional test you write. An officially maintained primitive removes that class of risk from your own codebase. If you are weighing whether a custom app is the right answer at all, our overview of custom Shopify apps is a useful starting point.
The deprecation deserves attention in its own right. Packages that no longer receive security fixes and that sit directly in an authentication path are a legitimate backlog item, not a nice to have. There is no forced migration and no removal date, so this is planning work, not firefighting.
Role-specific impact
- Marketers: no direct effect. The practical outcome is that internal tools you request, such as a promotion sync utility, can be built by the developers who already maintain your stack.
- Developers: a supported verification and token exchange path in PHP and Python, with retry handling built into the GraphQL client. Audit anything still on shopify-api-php or shopify_python_api.
- Store admins: nothing changes in the admin. When reviewing vendors, it is fair to ask which library their integration depends on and whether it is still maintained.
Use-case example
Real-world scenario
A manufacturer runs a Django service that pushes contract pricing from its ERP into Shopify and listens for order webhooks. The team wrote its own verification layer three years ago: signature checking, replay protection, token refresh, and the tests around them. It runs to roughly 400 lines and it reappears in every security review because nobody wants to be the person who signs off on custom crypto.
Moving to the official package reduces that layer to a single verification call and a single token exchange call, under 40 lines including error handling. The migration was scoped one route at a time, starting with the webhook endpoint, and the recurring review item disappeared with it.
Implementation checklist
- Inventory internal apps and services that call the Admin API from PHP or Python.
- Flag anything on shopify-api-php or shopify_python_api, since those receive no further security fixes.
- Install the new package in a branch: composer require shopify/shopify-app-php, or pip install shopifyapp.
- Migrate one route first, typically webhook or App Home verification, and confirm behaviour on a development store.
- Verify that token exchange returns an access token and that refresh works before touching production traffic.
- Budget scaffolding time, since no app template exists for either language.
- Keep React Router as the default for new public apps unless your team's stack argues otherwise.
FAQ
Q: Do we have to migrate existing PHP or Python apps?
A: There is no forced migration and no removal date. The old libraries keep working, but no new features or security fixes are coming, so treat migration as scheduled security work.
Q: Is there a starter template?
A: No. Both packages are framework agnostic primitives, so you scaffold in Laravel, Symfony, Django, FastAPI, or plain code and compose only what you need.
Resources
Shopify documentation: Libraries and templates.
Need guidance? Talk to Makro.