An API token is a secret string that a client application sends with each request to an API to prove its identity and what it is allowed to do.
What is an API Token?
API tokens typically cover a range of purposes beyond simple authentication: they scope what a request can do, such as read-only versus write access, identify which user or service is acting, and set how long that access lasts before it must be renewed. Teams usually issue different token types for different trust levels, a long-lived key for a trusted backend server, and a short-lived token for a client app or browser, since the two environments carry very different risks if a token leaks. A common variant is the distinction between opaque tokens, which are meaningless strings the server looks up in a database, and self-contained tokens like JWTs, which carry their own signed claims and can be validated without a database lookup. One caveat worth noting is that a token is not the same as an API key: a key typically identifies an application or developer account, while a token typically identifies a session or a specific scoped action, and the two are often used together in the same request flow.
Why API Tokens Matter
Tokens separate authentication from the user's password. A user signs in once, the server issues a token, and the app presents that token on every subsequent request, so the password is never sent again and can be rotated without breaking the app. For an engineering team, tokens make it possible to scope access precisely: one token can read a feed, another can post on behalf of a user, a third can only be used from a trusted backend. For a security team, a compromised token can be revoked in isolation, without forcing every user to reset credentials. In a social app, where every action is tied to a user identity, the token is what binds a request to the right user.
Types of API Tokens
| Type | Issued to | Lifetime | Safe location |
|---|---|---|---|
| API key | An application or developer account | Long-lived, manually rotated | Server only, never in a mobile app |
| Access token (bearer) | A user session | Short, often minutes to hours | Client, sent in the Authorization header |
| Refresh token | A user session | Long, revocable | Secure client storage |
| JSON Web Token (JWT) | A user or service | Short, self-contained with signed claims | Client or service |
| Scoped or restricted token | A specific action or resource | As short as the task | Client, for one narrow purpose |
Worked example of how these fit together: a user opens a brand's app. The app's own backend authenticates the user and requests a user-scoped access token from the social infrastructure using a server-side API key. The backend returns the access token to the app, which uses it for 60 minutes to load feeds and send messages. When it expires, the app asks the backend for a new one. The API key never leaves the server; the access token can only act as that one user; and if either is compromised, the blast radius is limited to what that token could do.
API Tokens and social.plus
social.plus is integrated through APIs and SDKs, and access is controlled with tokens in exactly this pattern: a server-side key for the brand's backend, and user-scoped tokens that the brand's app uses to act as a specific user across feeds, groups, chat, live streaming, and stories. This keeps the brand in control of who its users are, since the brand's own backend decides which user to issue a token for, while the social.plus infrastructure enforces what that user can do.
Key Takeaways
- An API token proves a client's identity and permissions on each request, so the password is never sent again.
- API keys belong on servers; short-lived, user-scoped access tokens belong in the app.
- Scoping and short lifetimes limit the damage a leaked token can do and make revocation surgical.
- In social infrastructure, the token is what ties every post, message, and reaction to the correct user.