Authentication

Use an API key for your own integrations. The official SellApp CLI uses OAuth on supported v2 endpoints and manages its credentials for you. Two headers identify the caller and select a store:

• Authorization: Bearer … contains your API key or OAuth access token.
• X-STORE selects the store by its slug, such as launch-lab.

The CLI sends its OAuth access token and X-STORE on store business requests. Your current store permissions, approved scopes, and selected stores constrain its access. Follow CLI authorization to connect it with sellapp login. OAuth is not available for custom applications.

Profile, accessible-store, and installation-management operations use OAuth without X-STORE; the effective-permissions operation requires it. Customer Portal endpoints use a 15-minute customer-session bearer token and return only that customer's redacted resources. Do not swap these token types: each endpoint reference names the credential it expects.

The base URL is https://sell.app/api. Requests operate on the real data of the selected store; SellApp does not provide a separate API sandbox.

Authentication with a secret API key

Send your key in the Authorization header, with the word Bearer and a space before it. Keep this on your server: never put a secret key in browser code, mobile app bundles, public repositories, or screenshots.

Set SELLAPP_API_BASE_URL, SELLAPP_API_KEY, and SELLAPP_STORE as shown in the quickstart.

curl --request GET \
  --url "${SELLAPP_API_BASE_URL}/v2/invoices" \
  --header "Authorization: Bearer ${SELLAPP_API_KEY}" \
  --header "X-STORE: ${SELLAPP_STORE}" \
  --header 'Content-Type: application/json'

Creating and managing a secret API key

If you do not already have a secret API key, you can generate one in your store developers settings. Always keep your API key safe and rotate it if you suspect it has been compromised.

API keys belong to an account, not a storefront. Each key has abilities: permissions such as listing for catalog access or invoice for purchases. Enable only the abilities your integration needs.

Both the key and the account must have permission for an operation. Store owners still need the relevant key abilities; staff accounts also need the matching store permissions. Provider limits and resource-state rules still apply.

Affiliate payout endpoints manage records of payments arranged by the merchant. Their permissions do not authorize SellApp to transfer funds. Customer wallet and credit endpoints separately manage customer prepaid credit.

If your account is part of a storefront as support staff, you can only access resources that your account has been given permission to manage. For example, a support staff account limited to tickets cannot modify products or create groups through the API.

Every response includes an X-Request-ID. Log it for support and debugging, but never log the bearer key.

Multiple stores

Send X-STORE on every store business request to select the intended store. OAuth requires it. Ordinary API-key routes can fall back to the account's current or first available store when it is omitted; routes that explicitly require the header reject its omission. Always send it so a change in the account's current store cannot redirect your integration's work.

The value is the storefront slug, not its numeric ID. A wrong or unknown slug returns 404; a valid store that the account cannot manage returns 403.

If you want to access launch-lab.sell.app, you would pass the slug launch-lab via the X-STORE header:

curl --request GET \
  --url "${SELLAPP_API_BASE_URL}/v2/invoices" \
  --header "Authorization: Bearer ${SELLAPP_API_KEY}" \
  --header "X-STORE: ${SELLAPP_STORE}" \
  --header 'Content-Type: application/json'

Using an SDK

An SDK can handle request setup for you, but check that it sends both the bearer key and X-STORE. A library does not change the permissions your key needs.

For currently known packages and integrations, see SDKs & Extensions.