Sign Customiser

Authentication and key lifecycle

Copy page

Create, store, rotate, and revoke Store-scoped API keys safely.

API v3 uses bearer API keys. Each key belongs to one Store, and every request acts only as that Store.

Create a key

Open the Store you want the integration to use, then go to Tools & Settings and choose API Tokens.

  • Shopify: open Sign Customiser from the Shopify admin for the intended store, then open Tools & Settings > API Tokens.
  • Universal: select the intended Store with the Store switcher, then open Tools & Settings > API Tokens. You can also use the API Tokens sidebar link.

If your Company has several Stores, create a separate key while each Store is selected. A key cannot switch Stores, and a Store ID in a request never changes its access. Call GET /api/v3/stores/me after setup to prove which Store the key belongs to.

Give the key a name that identifies its owner and purpose, such as Warehouse reporting. Select only the scopes it needs. You may also set an expiry date. Expired keys stop authenticating and must be replaced; expiry does not rotate a key automatically.

Store the secret once

The full sc_live_... or sc_test_... secret is shown once, immediately after creation. Put it in your deployment platform’s secret store or password manager before closing the dialog. Do not commit it, paste it into source code, or send it in chat.

Send the key in the bearer header:

http
Authorization: Bearer sc_live_...

Never put a key in a URL or query parameter. URLs are commonly recorded in browser history, proxy logs, and analytics.

Choose scopes

Scopes use the form resource:read or resource:write. A read scope does not grant writes, and a write scope does not imply a read scope unless both are selected. The endpoint reference names the required scope for each operation.

Start narrow. For example, the cold-start quickstart needs only:

  • store:read
  • customisers:read
  • pricing:read

A valid key with the wrong scope returns 403 insufficient_scope. That response lists required_scopes and granted_scopes, so you can update the integration or issue a replacement key without guessing.

Review, rotate, and revoke

The API Tokens page shows each key’s name, scopes, expiry, and last-used time. Last used means the key authenticated a request. A valid request that later fails its scope check can still update this time, so do not treat it as proof that the requested operation succeeded.

Rotation is create, replace, verify, then revoke:

  1. Create a new key with the same or narrower scopes.
  2. Update the integration’s secret and make a test request.
  3. Confirm the new key’s last-used time changes.
  4. Revoke the old key.

Revocation is immediate. Requests with that key then return 401 invalid_api_key. Revoke a key at once if it appears in source control, logs, a ticket, or any other place that is not an approved secret store.

Legacy keys

Older API keys may be labelled Legacy. They carry wildcard access for compatibility: they continue to work on the previous-generation API and currently satisfy v3 scope checks. New scoped sc_live_... and sc_test_... keys work only with v3.

Do not create new integrations around a legacy key. Replace one with a scoped key, test the v3 calls the integration uses, then revoke the legacy key. The legacy label describes the key’s access model; it is not a promise of permanent support.