Theme Access Password vs Admin API Token: Which One Do You Need?

Why the wrong ask costs you a week

Every client project starts with the same email: "Can you give me access to the store?" What happens next decides whether you're building on Tuesday or still waiting on Friday.

Ask for "admin access" and you've handed the merchant a decision they're not qualified to make quickly. Their finance lead gets involved. Someone asks whether you'll be able to see revenue. The request sits for four days and comes back as a staff invite with the wrong permissions, or a shared login you shouldn't be using.

Ask for a Theme Access password and you've asked for something narrow, revocable, and obviously safe. It takes the merchant about ninety seconds and no internal approval.

Theme Access password: for moving theme files

A Theme Access password comes from Shopify's Theme Access app, which the store owner installs. They enter your email, Shopify generates a credential prefixed shptka_, and it's emailed to you directly — the merchant never sees the token.

It grants exactly one thing: theme read and write on that one store. No orders, no customers, no payouts, no app management.

What makes it the right default

• No staff account required. On Shopify plans, staff seats are finite and adding contractors to them is a real cost. This sidesteps that entirely.
• Non-interactive. The CLI can authenticate from config instead of opening a browser, which matters for automation and for keeping a long-running dev session alive.
• Independently revocable. Project ends, merchant uninstalls the app or deletes the password. Nothing else in their store is affected.
• Per-store by design. One credential can't accidentally reach a different client's store.

[environments.default]
store = "client-store.myshopify.com"
password = "shptka_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
theme = "123456789"

With that file present the CLI reads auth from config, so theme pull, theme push and theme dev all run without a browser round-trip. That's also what stops an interactive logout from deleting a development theme mid-project.

Admin API token: for knowing what’s on the store

A Theme Access password moves files. It can't tell you that the store has a product called "Variety Pack" at /products/variety-pack. For that you need an Admin API token from a custom app, which the merchant creates in Settings › Apps and sales channels › Develop apps.

The token is prefixed shpat_ and does only what its scopes allow. For theme work, read-only scopes are enough:

Why this matters for client review

Without it, previews get generic. You send a link to a product template attached to whatever product happens to be first in the catalogue, and the client reviews a page that isn't representative. With it, each template gets pinned to the real page it applies to — the actual bundle product, the actual lookbook page — so what the client reviews is what their customers will see.

The third option: collaborator accounts

A collaborator request is a Partner-account request for access to a client store. It doesn't consume a staff seat, and the merchant can grant section-by-section permissions — themes only, if they choose.

It's genuinely useful, but it solves a different problem: it gets you, the human into the admin. It doesn't give a long-running process a credential. If you need to click around the theme editor, check an app's settings, or look at what a merchant is describing, a collaborator account is the right tool.

Most Shopify theme projects want the first two, and often the third. Very few want anything beyond that.

How to ask so you get it the same day

Access requests stall because they're vague and the merchant can't tell what they're agreeing to. Be specific about scope, purpose and reversibility, and the objection disappears.

Wording that works

Something close to this tends to get approved without a meeting:

If you send client-facing emails often, it's worth keeping this as a template.

Credential hygiene across a client portfolio

One store is easy. Fifteen is where this becomes a liability. Two failure modes show up repeatedly at agencies:

1. Tokens in plain text. Theme Access passwords in a shared spreadsheet, a Slack DM, or committed .env files. Every one of those can overwrite a live store.
2. Nothing gets revoked. Projects end, developers leave, credentials keep working. Two years later a former contractor still has theme write on a store you're responsible for.

What holds up at scale:

• One credential per store, never reused across clients
• Stored encrypted at rest, not in a spreadsheet or a chat thread
• Written to CLI config at run time and scoped to that session, rather than living permanently on developer laptops
• Revoked at project close as a checklist item, with the client told it happened
• Rotated when someone leaves the team

How ThemeSync handles credentials

• Credentials are stored once per store, encrypted at rest. Theme Access password and Admin API token live against the store, not in a spreadsheet and not on individual laptops.
• CLI config is written at run time. Auth is placed where the Shopify CLI needs it for the duration of a session with restricted permissions, rather than persisting in a checked-out repo.
• Non-interactive by default. Because auth comes from config rather than a browser login, long-running dev sessions don't get killed by a logout — which is what otherwise deletes a development theme.
• The API token powers template mapping. Read scopes on products, collections, pages and blogs are what let each template be pinned to the real URL it applies to, so client previews show real pages.
• Team members share store access without sharing tokens. Designers and QA work against a store through their role, and no one needs the raw credential pasted to them.

The practical effect is that "who can write to this client's live theme" has an answer you can give in one sentence.

Takeaways

• Theme Access password (shptka_) moves theme files. It's the right default ask, needs no staff seat, and works non-interactively.
• Admin API token (shpat_) with read scopes lets you list real products and pages, which is what makes previews representative instead of generic.
• Collaborator accounts get a human into the admin. Different job — request one when you need to click around.
• Never ask for order or customer access for theme work. There's no reason to have it and it slows approval to a crawl.
• Ask narrowly and explain reversibility, and access lands the same day instead of the following week.
• One credential per store, encrypted, revoked at close. If you can't audit who has theme write on which store, start there.