How to Show Shopify Store Revenue Without Admin Access

Oct 18, 2026 · 4 min read · #Shopify #Verified revenue #Guides

If you run a Shopify store and want to show Shopify revenue publicly, you have three choices. You can post a screenshot, you can give someone access to your admin, or you can hand a tool a narrow, read-only credential that can see orders and nothing else. This guide is about the third option, and about what changed in 2026 that trips a lot of store owners up.

Why not just share a screenshot?

Screenshots are fine for a quick update to friends. They are weak as proof. Anyone can crop out refunds, pick a lucky week or edit the number in a browser's dev tools in about ten seconds. People who follow store owners online know this, so a screenshot rarely settles the question "is this real?"

Giving out admin access is the opposite problem: it proves everything and risks everything. A staff account can see customer details, change products and issue refunds. You do not want that for a public number.

The middle ground is an app credential with a single permission: read orders. A tool holding that credential can add up your sales and show the total. It cannot touch products, customers' payment details, settings or payouts.

What changed with Shopify custom apps in 2026

For years the easy route was a "custom app" created right inside your store admin (Settings, then Apps and sales channels, then Develop apps). You ticked some scopes and Shopify showed you an Admin API access token starting with shpat_. You could copy that token into any tool.

Starting January 1, 2026, Shopify stopped letting merchants create new legacy custom apps from the admin. Apps created before that date keep working. New apps are made in the Dev Dashboard instead.

The catch is that Dev Dashboard apps do not show you a static token. You get a Client ID and a Client secret, and software exchanges those for a short-lived access token using what Shopify calls the client credentials grant. According to Shopify's docs, tokens from that grant last 24 hours and the grant only works when the app and the store belong to the same Shopify organization. In practice that means: create the app yourself, under the same account that owns the store.

This is why so many forum threads in 2026 start with "where did my access token go?" It did not go anywhere for old apps. New apps just work differently.

Step by step: a read-only Dev Dashboard app

These are the general steps. Shopify moves buttons around from time to time, so follow the labels rather than exact positions.

  1. Open the Shopify Dev Dashboard while logged in to the account that owns your store.
  2. Create a new app. Give it a name you will recognise later, like "revenue display".
  3. In the app's configuration, set the Admin API access scopes. Add read_orders and nothing else.
  4. Release a version of the app so the scope takes effect.
  5. Install the app on your store.
  6. Open the app's settings and copy the Client ID and Client secret.

Treat the Client secret like a password. Paste it only into a tool you trust, and only into a field built for it, never into a chat or a public repo.

If you already have a legacy custom app from before 2026 with the read_orders scope, its shpat_ token still works. You can keep using it.

What "read_orders" can and cannot see

The read_orders scope lets an app read order records: totals, line items, refunds, financial status, test flags and so on. It does not let the app create or edit orders, change products, move money or change store settings. If the credential leaks, the damage is limited to someone reading order data. That is still worth protecting, but it is a very different risk from a leaked admin login.

If you ever want to cut access, uninstall the app from your store or rotate the secret. The tool will stop being able to read anything.

How to count Shopify revenue honestly

Raw "total sales" can mislead in both directions. A fair public number usually:

  • covers a fixed window, such as the last 30 days, so it is comparable over time
  • subtracts refunds, so returns do not inflate the figure
  • excludes cancelled orders, which never turned into real sales
  • excludes test orders, which you placed yourself while setting up payments

Write down which rules you use. If you post a number somewhere, someone will ask how it was counted, and "last 30 days of orders, net of refunds, no cancelled or test orders" is an answer people can check against their own expectations.

Where to show it

Once you have a trustworthy number, put it where people already look:

  • your link in bio, next to the store link
  • your "about" or founder page
  • a build-in-public thread or monthly update

The value is in keeping it current. A number that updates on its own beats a screenshot from last spring.

Doing this with makerhandle

On makerhandle each project can connect Shopify with either a Dev Dashboard app (Client ID and secret) or a legacy token with read_orders. We add up the last 30 days of orders net of refunds, skipping cancelled and test orders, and the figure gets a check mark on your page and on the public leaderboard. Credentials are encrypted at rest and never shown again. The same works for Stripe if you also sell subscriptions; see how to show verified MRR.

If you run a store, makerhandle for Shopify stores shows how it looks on a page, and verified revenue explains the details.

Put all your projects on one page

Status, verified revenue and stats. Free for up to 5 projects.

Claim your handle

Keep reading

Oct 14, 2026 · 4 min read

How to Show Verified MRR Publicly (Stripe Guide)

A step-by-step guide to showing verified MRR from Stripe with a read-only restricted key, what read-only really means, and why it beats a screenshot.

Oct 7, 2026 · 4 min read

Link in Bio for Founders: What to Put on It

What a founder link in bio should include: projects, status, revenue, contact and a short bio. With example structures for first-time and serial founders.

Sep 30, 2026 · 4 min read

Building in Public: Sharing Revenue and Failures

A practical guide to building in public: what revenue to share, how to talk about failures, listing dead projects honestly, and when to stop.