Theme scopes
Scopes are checked exactly:
write_themes does not imply read_themes, so an agent that edits
themes needs both. Theme check and preview are read_themes so a reviewer key can run them without
being able to change anything.
OAuth tokens carry the scopes the merchant ticked on the consent screen, for one store.
Static sq_agt_* keys carry the scopes chosen when the key was created under
Agents → Access → API keys. Tokens issued to third-party apps are never widened by a super-scope:
a token grants its listed scopes and nothing else.
Publishing and approval
publish_themes is a spend-class scope: publishing changes what every customer sees. Whether a
publish waits for a person is a store setting, agent_theme_publish_policy, set in the dashboard
under Settings → Developer → Build with your agent → Agent theme publishing:
Either way the call returns
202:
Approving
The merchant approves or denies it in Settings → Developer → Build with your agent → Theme publish approvals (Approve & publish or Deny). An integration holdingagent:admin can resolve it
through the API instead:
What a publish does
A theme publish is the same publish the dashboard runs:- Theme check runs in publish mode. Any error returns
422 CHECK_FAILEDwith the full result, and nothing is published or parked for approval. - The theme becomes the live (
main) theme, the storefront is deployed, and the search-engine bake runs. - The webhook
theme.publishedfires on success, ortheme.publish_failedon failure.
GET /themes/{id}/publish-status
(the get_publish_status tool).
What the agent should do with pending_approval
Tell the person it is waiting for their approval, and stop. Do not call publish again while it waits.
Poll get_publish_status, or subscribe to the theme.published webhook.
Audit
Every theme call — reads included — is written to the agent audit log with the key that made it. Every successful write batch is recorded as a theme version whose author isagent:<key name>, so a
version from an OAuth connection reads agent:OAuth: <client name>.