Get user info server-side

Sometimes your backend needs to know a user's current state while the user isn't active in your app — a scheduled job checking whether a subscription is still active, an external service acting on the user's behalf, or any async flow that runs without a browser session. The UserInfo API covers this: your server fetches a tiun user's current email and productAccess using only their userId and your API key. No token, no user present.

---

User info vs. verification

Server-side authentication verification answers "is this request really coming from a signed-in user?" — it exchanges a short-lived token and returns isAuthenticated.

The UserInfo API answers "what is the current state of a user I already know?" — a plain lookup by ID. It doesn't authenticate anyone: anyone with your API key and a userId gets the data. Use it for server-initiated flows, and keep using verification to gate incoming requests from your frontend.

---

How it works

1. Capture the tiun userId while the user is in your app — from the user object in a userChange payload, or from userInfo.userId on a verified request — and store it with your own user record.
2. Later, your server calls the tiun UserInfo API with that ID and your API key.
3. The response carries the user's current userId, email, and productAccess — check productAccess for the product you care about.

---

Setup: API key

The endpoint is protected by an API key — the same one used for server-side verification. If you don't have one yet, create it in the dashboard: open APIs in the sidebar and click Create new key. Store it securely in your backend environment variables.

---

Call the endpoint

Endpoint:

GET /live_api/s2s/v1/users/{userId}/info

Base URLs:

Environment	URL
Live	https://api.tiun.live
Sandbox	https://api-sandbox.tiun.live

Use the base URL and API key from the same environment the userId belongs to — live and sandbox users are separate, and API keys are not shared between environments.

Header: X-TIUN-API-KEY: <your-api-key>

No request body — the userId travels in the path.

Response codes:

Status	Meaning
200	User object returned — read the body
400	The request is invalid
401	API key is invalid
404	The user does not exist

A 200 response carries the user object:

{
  "userId": "u-...",
  "email": "[e-mail]",
  "productAccess": ["p-live-pro"]
}

Unlike the verification response, there is no isAuthenticated wrapper — the lookup isn't tied to a session, so the body is just the user's current state.

---

Full example

A reusable check your backend can run from anywhere — a scheduled job, a queue worker, or a service handling a user who isn't in the app right now:

const BASE_URL = process.env.TIUN_API_BASE || 'https://api-sandbox.tiun.live';
const API_KEY = process.env.TIUN_API_KEY;

async function hasActiveSubscription(userId, productId) {
  const response = await fetch(
    `${BASE_URL}/live_api/s2s/v1/users/${userId}/info`,
    {
      headers: { 'X-TIUN-API-KEY': API_KEY },
    },
  );

  if (response.status === 404) {
    // unknown user → no access
    return false;
  }

  if (response.status !== 200) {
    // API key invalid or upstream error → fail closed
    return false;
  }

  const user = await response.json();
  return user.productAccess.includes(productId);
}

// e.g. in a background job:
const isActive = await hasActiveSubscription('u-abc123', 'p-live-pro');

productAccess reflects what the user has paid for right now — tiun keeps it consistent through renewals, cancellations, and payment failures, so there is nothing to cache or reconcile on your side. See Product access in Reference.

---

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.