Every Store API request must carry an Authorization header with a bearer token. There is no API-key query parameter, cookie auth, or HTTP basic — Bearer-only. A request without a token returns 401; a request whose token lacks the scope the endpoint requires returns 403.
GET /api/2025-01/reference/currencies HTTP/1.1
Host: api-store.tringify.com
Authorization: Bearer YOUR_STORE_API_TOKENToken types#
There are three token shapes. All are sent the same way and accepted by the same endpoints; the prefix tells you which one you hold and where it came from.
Prefix |
Issued by |
Lifetime |
Granted to |
|---|---|---|---|
|
Installing an app on a store (OAuth) |
Long-lived |
The app, with the scopes it declared at install — valid only while the app stays installed and active |
|
The App Bridge session flow (embedded apps) |
Short-lived (~15 min) |
One browser session of an embedded app — mint a fresh one per session |
|
A store admin in the Tringify admin |
Until revoked or its expiry |
Whoever holds the token, with the scopes the admin selected when creating it |
Getting a token#
App tokens (tpat_) are issued when a merchant installs your app. The merchant approves the full scope list during install; the token is returned to your app at the end of the OAuth flow and stays valid while the app remains installed and active.
Session tokens (tast_) are minted by the App Bridge session flow for embedded apps that call the Store API from the browser. They are short-lived by design — request a new one each session rather than storing it.
Admin tokens (tsat_) are created by a store admin in the Tringify admin under API access. The admin picks the exact scopes and can rotate or revoke the token at any time. Use these for scripts and server-to-server integrations you run yourself.
Scopes#
Each endpoint declares the scope it requires (for example read_products, write_products). The token must include that scope or the response is 403. GET /api/2025-01/scopes lists every scope the platform defines.
An app's scopes are fixed at install time — the merchant approves the full list before the token is issued. To request additional scopes, the app must be re-installed with the new list. Admin tokens carry exactly the scopes the admin chose when creating them; issue a narrowly-scoped token for a one-off script, or a broader one for trusted internal use.
Token lifecycle#
A token can stop working before you expect it to. Handle 401 by re-authenticating, not by retrying the same token.
- **`tpat_`** stops validating the moment the app is uninstalled, suspended, or terminated — even though the token string itself is unchanged.
- **`tast_`** expires after about 15 minutes; mint a fresh session token rather than caching one.
- **`tsat_`** is valid until the admin rotates or revokes it, or until its expiry if one was set. A rotated token invalidates the old value immediately.
Rate limits#
Every response carries the current rate-limit state so you can back off before you are throttled:
- `X-RateLimit-Limit` — requests allowed in the current window.
- `X-RateLimit-Remaining` — requests left in the window.
- `X-RateLimit-Reset` — when the window resets (Unix seconds).
App tokens (tpat_ / tast_) are limited per app per store; admin tokens (tsat_) share one bucket per store. Exceeding the limit returns 429 with a Retry-After header (seconds) — wait that long, then retry. See Rate limits for the full policy.
Auth-related errors#
Status |
Code |
When it fires |
|---|---|---|
401 |
|
Token missing, malformed, or expired — re-authenticate. Never retry the same token. |
403 |
|
Token is valid but does not include the scope the endpoint requires — do not retry; the merchant must grant the missing scope. The message names the required scope. |
429 |
|
Rate limit exceeded — wait for the |
Branch on error.code, never on error.message — the message is locale-dependent. The full error envelope is documented on Errors.