Shopify shipped official PHP and Python app packages, and a list of the mistakes you were making

Shopify's app tooling has been JavaScript-first for years, with Ruby along for the ride. If you worked in PHP or Python you got a thin API client and were left to implement session tokens, request verification, and token exchange yourself. On August 26 that changed: both languages now have official, GA, first-party packages.

The headline is a fair bit less interesting than what is inside them. These packages ship an explicit "common misuses to avoid" table, which is Shopify writing down the security mistakes it sees most often in real apps. That list is worth reading whatever language you build in, because most of the entries are mistakes you can make just as easily in Remix.

What they actually give you

Initialisation is two credentials the Shopify CLI already provides:

1import os2from shopify_app import ShopifyApp3 4shopify = ShopifyApp(5    client_id=os.getenv("SHOPIFY_API_KEY"),6    client_secret=os.getenv("SHOPIFY_API_SECRET"),7)

1<?php2 3use Shopify\App\ShopifyApp;4 5$shopify = new ShopifyApp(6    clientId: getenv('SHOPIFY_API_KEY'),7    clientSecret: getenv('SHOPIFY_API_SECRET'),8);

From there you get one verification function per surface, rather than a single generic one you have to configure correctly:

• verify_app_home_req for the embedded app home, verify_app_proxy_req for storefront requests through an App Proxy, and verify_webhook_req for webhooks.
• One each for the extension surfaces: verify_admin_ui_ext_req, verify_checkout_ui_ext_req, verify_customer_account_ui_ext_req, verify_pos_ui_ext_req, verify_flow_action_req.
• exchange_using_token_exchange and exchange_using_client_credentials for getting access tokens, plus refresh_token_exchanged_access_token which decides for itself whether a refresh is needed.
• admin_graphql_request for Admin API calls, with retry handling built in.

Splitting verification per surface is the right call. The surfaces genuinely differ in what they sign and how, and a single verify() with a mode flag is exactly the shape that leads to someone verifying a webhook as though it were an App Bridge request.

The part worth reading in any language

Here is the table, paraphrased from the package README. Read it as a list of the mistakes Shopify sees most often, because that is what it is.

One design decision worth noticing

The two packages deliberately share an API. Shopify's own stated reasoning is that this "creates some interesting constraints, and sacrifices some idioms," but means a fix in one community benefits the other.

That is an unusual trade to make on purpose, and it explains a few things that will feel slightly un-Pythonic or un-PHPish when you use them. It is also why the Python package asks you to convert your framework's request into a plain dict rather than accepting a Django or FastAPI request directly: the shared surface cannot know about your framework. Slightly more boilerplate, one integration path to document, and no risk of the Django adapter and the Flask adapter drifting apart on something security-critical.

The packages are also explicit about scope: they target what most apps need most of the time, and skip less common cases such as non-embedded apps. Worth checking against your architecture before you commit.

Should you use them?

Starting something new in PHP or Python: yes. The old libraries are deprecated, and hand-rolling session-token verification is exactly the kind of security-critical work you should not be doing yourself.

Running an existing app on the old libraries: no rush. Nothing is being switched off and the new packages are designed for incremental adoption, one route at a time. That is a real contrast with the script tag deprecation, which has hard dates and no opt-out. Migrate this at your own pace; do that one on Shopify's schedule.

Building in JavaScript: read the misuses table anyway. It costs two minutes and most of it applies to you. And if your app is mostly a frontend over Shopify's own data, a Static App may remove the question entirely by removing the server.

The wider read: Shopify is steadily converting tribal knowledge into shipped defaults. Events replaced payload-diffing, the analytics platform replaced everyone's home-grown dashboard stack, and now request verification stops being something each app reimplements slightly differently. The work that remains is the judgment about what to build, which is the part that was always worth your time.