Skip to main content

API Authentication

The LaunchMyStore API uses OAuth 2.0 for authentication. This page covers the authentication methods available and how to use them in your API requests.

Authentication Methods

Access Tokens

OAuth 2.0 access tokens for server-to-server API calls

Session Tokens

JWTs for embedded app API calls

Access Tokens

Access tokens are obtained through the OAuth 2.0 flow and used for server-to-server API calls.

Obtaining Access Tokens

Your app receives its authorization code through the managed install handoff: when a merchant installs (or reinstalls) your app, LaunchMyStore redirects their browser to your /auth endpoint with code, state, and an HMAC signature. Do not redirect merchants to GET /apps/oauth/authorize yourself — that endpoint is a merchant-authenticated JSON API used by the LaunchMyStore admin, and a top-level browser redirect returns 401.

Using Access Tokens

Include the access token in the Authorization header:

Token Expiration

Access tokens expire after 24 hours. Use the refresh token to get a new access token:
Refresh tokens expire after 30 days. If a refresh token expires, the merchant must re-authorize your app.

Token Management

Implement a token manager for automatic refresh:

Session Tokens

Session tokens are JWTs used for embedded app API calls. They’re obtained through App Bridge.

Getting Session Tokens

Using Session Tokens

Include in the Authorization header:

Verifying Session Tokens

Verify session tokens on your backend:
See Session Tokens for detailed documentation.

Scopes

Request only the scopes your app needs:

Store Data Scopes

Order Scopes

Customer Scopes

Content Scopes

Admin Scopes

Billing & Analytics Scopes

Settings & Marketing Scopes

Rate Limits

API requests are rate limited based on your app’s billing tier: The limit is a flat per-second sliding window per (app, store); there is no separate burst allowance.

Rate Limit Headers

Every response includes rate limit information:

Handling Rate Limits

Error Responses

Authentication Errors

There is no machine-readable code string — branch on the HTTP status. The message is carried in errors.base[0].

Error Response Format

Errors use the standard { errors } body:

Handling Errors

Security Best Practices

Never include your client secret in client-side code. Keep it on your backend only.
Always use HTTPS for API calls and webhook endpoints.
Always validate the state parameter in OAuth callbacks to prevent CSRF attacks.
Encrypt access and refresh tokens in your database. Never log them.
Only request the scopes your app actually needs. Merchants trust apps with fewer permissions.
Tokens can be revoked if a merchant uninstalls your app. Handle this gracefully.

Testing Authentication

Test Mode

Use test credentials for development:

Mock Tokens

For unit testing, create mock tokens:

See Also