Hey guys, first time posting - not sure if this is the right board/topic.
I had the following idea - I do some work on Shopify themes, and noticed that the online Shopify editor is basically VS Code (monaco) but online. That got me thinking, it would be cool if it had agentic coding, like Cursor, to make things a little bit easier.
Anyway, after a little bit of digging, I figured out how to download my own theme files & assets, to my device locally - via undocumented API endpoints. The endpoints are the same ones that the online editor uses to fetch assets for itself, so I just did the same API calls and CURL-ed the files to my laptop. One of the endpoints I used in my testing is /api/app_proxy/${shop}?operation=FetchThemeFiles&version=unstable
I know that it’s not the official or recommended way, but it’s way faster than using the Admin API or the Shopify CLI. I’m also aware that the parameter version=unstable means Shopify can (and probably will) change how the endpoint works - I’m not too concerned about that, this is all theoretical and a tech demo anyway.
Now here’s my actual question: am I going against TOS or any policies here? Am I allowed to do this? I was thinking, if this turns out mildly viable or useful, maybe I can open source it for other merchants, perhaps they find it useful.
Interesting experiment! From a technical perspective, it’s impressive that you traced the same requests the online editor is making. However, I’d be cautious about building anything that depends on undocumented internal endpoints.
The fact that the endpoint is undocumented and uses version=unstable suggests it isn’t intended as a public interface and could change or disappear without notice. Even if it works today, there’s no guarantee it will continue to work in the future.
I also don’t think anyone in the community can give a definitive answer on whether this complies with Shopify’s Terms of Service or platform policies. That’s ultimately something only Shopify can clarify. If you’re planning to open source the project or encourage others to use it, I’d recommend getting confirmation from Shopify first.
For a production ready tool, I’d still recommend using the officially supported Admin API or Shopify CLI. They may not be as fast or convenient, but they’re documented, supported, and far less likely to break unexpectedly.
If this helped answer your question, please mark it as the solution so it can help others facing the same concern.
Nobody outside Shopify can give a binding answer on that, and building around an endpoint literally versioned unstable is asking for it to break without warning, especially if you plan to open source something others would depend on.
But worth pointing out: the actual problem you’re solving (Admin API/CLI feeling slow for pulling theme files) already has an official, fast solution - shopify theme pull via the Shopify CLI. It downloads your theme’s files and assets locally in one command, and it’s built specifically for local development workflows (editing locally, then shopify theme push or shopify theme dev for live reload). It’s not going through the same internal editor endpoint, but it’s the officially supported equivalent of what you’re trying to achieve, and in practice it’s fast enough for normal theme development - most theme devs use it as their default local workflow rather than the raw Admin API.
If your actual goal is the “agentic coding on theme files” idea rather than just fast downloads, theme pull + your own local tooling (feeding those files into whatever agentic coding setup you want, Cursor or otherwise) gets you the same result without depending on an endpoint that could vanish or change shape without notice - which matters a lot more if you’re planning to open source this for other merchants to rely on.
Thanks for the replies, everyone. I appreciate it!
As I mentioned, I’m fully aware that the API endpoint is undocumented, unstable, and could change at any time. I also know that the Shopify CLI makes theme development much easier for developers. The problem is that getting started with the CLI requires Node.js, Git, and a certain level of comfort using the terminal. That’s perfectly reasonable for Shopify developers, but it’s a very different story for the average merchant who has never worked with those tools.
In comparison, my undocumented API approach is simpler and quicker. As long as you can open the theme editor in your browser, you can access your theme files, download them locally, and push changes back almost immediately.
Sadly, Shopify Support wasn’t able to provide a definitive answer either. They actually referred me to the community forums for clarification. According to what they told me, this approach isn’t explicitly prohibited under the Terms of Service, but it’s discouraged because the API is undocumented and subject to change. Their recommendation was to use the Shopify CLI instead, but they stopped short of giving a clear yes-or-no answer on whether my approach is acceptable.
Perhaps it’s wiser to drop this instead of continuing, open-sourcing it and then potentially getting a cease and desist from Shopify
Cool experiment - nice bit of detective work tracing what the editor does under the hood. On your actual question : nobody here can give you a real yes/no on the TOS. Only Shopify can officially say whether this is allowed, so I wouldn’t treat any community reply (including mine) as a green light.
That said, a couple of practical flags. Anything undocumented with version=unstable is basically Shopify saying “this is internal and can change without warning.” It might work today and silently break tomorrow, so it’s a shaky base to build on. And there’s a difference between poking at your own store for fun versus shipping something other merchants rely on - the second one carries more risk if you’re leaning on private endpoints.
If you want to open-source it, I’d get confirmation from Shopify first (Partner/dev support is the right channel). For anything meant to be stable or shared, the Admin API or CLI is the safer bet - slower and less slick, but documented and supported, so it won’t disappear on you. Hope this helps
The stability and TOS angles are covered above, so the one I would weigh is the auth model, because it decides whether this can be a tool at all.
Those editor endpoints authenticate off your admin session cookie. That is fine while you are the one logged in, in that tab. The moment it is something other merchants run, you either ship a browser extension that lives inside their session, or you ask them to paste a session cookie to you. The second one is where a fun experiment turns into something nobody should install, and it is a bigger problem than the endpoint changing.
The other half is that your Node and Git objection does not really apply to the documented path anymore. Theme file management landed in the Admin GraphQL API in 2024-10. The store owner enables custom app development under Settings, then Apps and sales channels, then Develop apps, creates an app with read_themes, installs it, and copies the Admin API access token. After that it is one POST to /admin/api/VERSION/graphql.json with the theme query and its files connection. You get filename, size, contentType, checksumMd5 and body back, where body comes as text, base64 or a URL depending on the file. Cap is 50 filenames per query, so a whole theme is a few pages rather than one call.
No terminal, no Node, no CLI, and it does not break the day Shopify reworks the editor. Were you pulling whole themes, or a handful of files at a time?
That’s an interesting project, but I’d be cautious about relying on undocumented internal endpoints. Just because they’re used by Shopify’s own editor doesn’t necessarily mean they’re intended for public use or are covered by the same stability and support guarantees as the Admin API or Shopify CLI.
From a practical standpoint, the biggest risks are that the endpoint could change or be removed without notice, and using internal APIs may not align with Shopify’s platform expectations for public tools. If you’re considering open-sourcing it, I’d recommend reaching out to Shopify Developer support or reviewing the Partner Program Agreement and API Terms to confirm whether this type of access is permitted before investing further.
If your goal is to build a tool others can depend on, using the officially supported APIs and Shopify CLI is likely to be the more sustainable approach, even if they’re not quite as fast today.
