Verify subscriptions server-side
Subscription verification on the backend is identity verification plus a productAccess check. If your server serves data that should only be returned to subscribers of a specific product, this guide is what you want.
It uses the same endpoint as server-side authentication verification. The flow is identical up to step 3 — the only difference is what you check on the verified user object.

How it works
Your frontend asks tiun for a signed verification token.
It sends that token to your backend on protected requests.
Your backend exchanges the token with the tiun UserVerification API for the user object.
If
isAuthenticated: trueanduserInfo.productAccesscontains the required product ID, you serve the protected data.
The verified user object includes isAuthenticated plus a userInfo payload (userId, email, productAccess) — see User object and Product access in Reference.
Setup: API key
Create an API key in the dashboard under APIs, then store it in your backend environment variables. Same key as the one used for server-side authentication verification.
1. Get the verification token
Identical to the auth verification flow — call tiun.getUserVerificationToken() on the frontend and send the result to your backend as a Bearer token. See getting the verification token for the snippet.
2. Verify the token on your server
Same endpoint as the auth verification flow — POST the token to the tiun UserVerification API and read the user object from the response.
Endpoint:
POST /live_api/s2s/v1/users/verification
Base URLs:
Live
https://api.tiun.live
Sandbox
https://api-sandbox.tiun.live
Use the base URL and API key from the same environment as your frontend (sandbox: true in the SDK → sandbox URL and sandbox key). API keys are not shared between live and sandbox.
Header: X-TIUN-API-KEY: <your-api-key>
Body: { "userVerificationToken": "<token>" }
A 200 response carries the user object:
3. Check productAccess
productAccessOnce you have the user object, gate the response on two things:
isAuthenticatedmust betrue— the user is signed in.userInfo.productAccessmust include the product ID required by this endpoint.
Splitting these two checks lets you distinguish "not signed in" from "signed in but without the subscription" — useful UX feedback (prompt login vs. prompt upgrade).
Full round-trip
Frontend — request the protected resource when the user is authenticated:
Backend — exchange the token, check identity, then check product access:
Multiple plans
If you offer tiers (for example Light unlocks some endpoints, Pro unlocks all), check for the highest applicable tier first:
Live and sandbox are independent environments — each has its own API base URL and API keys. Use sandbox credentials while your app runs with sandbox: true; switch URL and key together when you ship live traffic. See Sandbox.
Last updated
Was this helpful?