Authentication

Every SellApp API request needs a secret API key. Two headers tell SellApp who is making the request and which store they want to use:

• Authorization: Bearer … identifies your account through its API key.
• X-STORE selects the store by its slug, such as launch-lab.

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_SLUG 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_SLUG}" \
  --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.

Financial endpoints use narrow abilities. seller-balance permits balance reads only, while seller-payout permits payout history, requests, cancellations, and configuration changes. Grant seller-payout only to integrations that must initiate or manage platform payout reservations.

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

Pass an X-STORE header with every authenticated request to specify which store you want to access. API keys are account-scoped, so this header ensures the request is sent to the intended storefront even when the account belongs to more than one store.

The value is the storefront slug, not its numeric database 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_SLUG}" \
  --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.