Developers | Shoppingate

Server side

Authentication

How your backend proves who it is to Shoppingate, and how it knows which user is using your Mini App. There are two parts: your server is identified by your Mini App's Vendor API Key on every call, and each user is identified once, by verifying the token your Mini App gets from ft.getUserInfo.

Every server-to-server call is authenticated with a per-mini-app Vendor API Key plus the X-Mini-App-Id header. Get the key from the merchant portal → your mini app → API keys. Rotate anytime; the previous key stays valid for 24 hours to give you a clean cutover.

# Every request carries these two headers
X-Vendor-Api-Key: sg_live_v2_<your-key>
X-Mini-App-Id: 42

Keep the key server-side. Never ship it inside the mini-app bundle or expose it in a page. If a key leaks, rotate it from the merchant portal immediately.

User authentication flow

The API key above authenticates your server to Shoppingate. To identify the user in front of the mini app, follow this three-step flow — the mini app reads the user's token from ft.getUserInfo, your backend verifies it against the platform, and from there you mint your own session token.

Get the user's token in the mini app, forward it to your backend

Inside the mini app, call ft.getUserInfo and read res.userInfo.token — the token for the signed-in Shoppingate user (see User info).

Verify the token with the Identity API and register the profile

Your backend calls POST /s2s/v1/identity/verify with the same token (see Endpoints).

Mint your own session token and use it inside the mini app

Once the profile is registered, mint your own session token (whatever your backend already uses — a JWT, an opaque cookie, an OAuth access token) and return it to the mini app. From here on, every mini-app → your-backend call uses your token. The Shoppingate token is verified once — steps 1 & 2 are a one-time handshake, not something to repeat on every request.