> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stmlink.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> 对外开放的服务端接口有两组前缀，都用同一套鉴权：`/server/v1/...`（SRTC 与 SMeeting 的主接口）和 `/stm/srvapi/v1/...`（SMeeting 的用户体系，服务端极简对接会用到）。鉴权是 app_id + nonce + timestamp + signature 四个请求头，用 app_key 做 HMAC-SHA256 签名，只能从业务方自己的后端调用。除这两组前缀外的接口均为内部接口，不要建议客户调用。 Public server APIs use two path prefixes with the same authentication: `/server/v1/...` (the main APIs of both SRTC and SMeeting) and `/stm/srvapi/v1/...` (the SMeeting user system, used by server-side low-code integration). Authenticate with four request headers, app_id + nonce + timestamp + signature, where signature is HMAC-SHA256 keyed with app_key; call these APIs only from the customer's own backend. Any other path is internal: never suggest calling it.
> app_key 是服务端密钥，绝不能出现在客户端代码、前端配置或移动 App 里。客户端加入频道用的 token 必须由业务方后端签发后下发（SRTC 走 `/server/v1/channel/grant`，SMeeting 走 `/stm/srvapi/v1/member/grant`）。 app_key is a server-side secret and must never appear in client code, frontend config, or a mobile app. The token a client uses to join must be issued by the customer's backend and passed down to the client (SRTC: `/server/v1/channel/grant`; SMeeting: `/stm/srvapi/v1/member/grant`).
> SRTC 与 SMeeting 是上下两层不同的产品，术语不通用：SRTC 是音视频底座，说「频道 channel」「加入 / 退出」；SMeeting 建在 SRTC 之上，说「房间 room」「会议 meeting」「进入 / 退出」。回答时按用户所在的层用对应术语，不要把「房间」「会议」安到 SRTC 的接口上，也不要用「频道」「加入 / 离开」描述 SMeeting 的概念（接口标识符原样保留）。 SRTC and SMeeting are two separate layers with different terminology. SRTC is the audio/video foundation: it has channels, and users join and leave a channel. SMeeting is built on top of SRTC: it has rooms and meetings, and members enter and exit a meeting. Answer in the terms of the layer the user is working with: never apply "room" or "meeting" to SRTC APIs, and never describe SMeeting concepts in prose with "channel", "join", or "leave" (API identifiers such as `force_join` keep their literal names).
> 同一能力在各端 SDK 里的包名、类名、方法名并不相同。写示例代码时请使用文档中该端自己的 API，不要把一个端的写法套到另一个端上。苹果平台每个产品都有两套 SDK（Swift 原生与 Objective-C），两套 API 不能混用。 Package, class, and method names differ between platform SDKs for the same capability. In sample code, use the API documented for that platform; never carry one platform's code over to another. On Apple platforms each product ships two SDKs (native Swift and Objective-C) whose APIs must not be mixed.

# Token and authentication

> How AppID and AppKey divide responsibilities, how your backend issues the token a client needs to join a channel, how to choose the uid, and the errors you hit when a token is reused or a signature is wrong. Read before writing any join logic.

A client needs a token to join a channel. This token **can only be issued by your backend**; it can't be generated on the client. This page explains the whole flow.

***

## AppID and AppKey

After you create an app, you get a pair of credentials with completely different responsibilities:

| Credential | Purpose | Allowed on the client |
| - | - | - |
| **AppID** | Identifies your app | Yes |
| **AppKey** | Secret key for signing server API calls | **Never** |

<Warning>
  **A leaked AppKey means your app is taken over.** Anyone who gets it can issue tokens for any user identity, remove users, and destroy channels.

  It must not appear in client code, frontend config files, mobile app packages, Git repositories, or logs. It may only exist on your own server.
</Warning>

***

## Issuance flow

```mermaid theme={null}
sequenceDiagram
    participant App as Your app
    participant Backend as Your backend
    participant SRTC as SRTC service

    App->>Backend: 1. Request to join a channel
    Note over Backend: 2. Verify user identity and permissions<br/>(your own business logic)
    Backend->>SRTC: 3. POST /server/v1/channel/grant<br/>HMAC-SHA256 signature with AppKey
    SRTC-->>Backend: 4. Return token
    Backend-->>App: 5. Deliver token
    App->>SRTC: 6. SDK joins the channel with the token
```

The key is step 2: **SRTC doesn't manage your user system**. Who is allowed into this channel and what identity they have once inside are entirely decided by your backend. SRTC only trusts the issued token.

For endpoint details, see [Server API · Get a channel join token](/en/rtc/server-api/channel); for the signing algorithm, see [Server API overview](/en/rtc/server-api/overview).

<Tip>
  If you don't want to set up a backend while debugging, you can generate a temporary token directly in the developer console to get the client flow working. **Temporary tokens are for debugging only**; production must issue tokens from your backend.
</Tip>

***

## Choosing the uid

The `uid` signed into the token is this user's identity in the channel. Think through two rules first:

* One uid **can join multiple different channels at the same time**
* When the same uid joins the **same** channel, the later join replaces the earlier one

So:

| Your requirement | How to choose the uid |
| - | - |
| A user can have only one online identity at a time (the usual case) | Use your system's user ID directly |
| The same user needs to be online on multiple devices at once without replacing each other | Combine "user ID + device identifier" or a sessionId into a unique value |

<Note>
  If what you need is meeting semantics such as "one user attending from multiple devices at once", SMeeting has a built-in mechanism that distinguishes identities by device type, so you don't have to build uids yourself. See [Choosing SRTC or SMeeting](/en/choose).
</Note>

***

## Validity and invalidation

A token is bound to one session and can't be reused after it has been used:

| Symptom | Server error code | Cause |
| - | - | - |
| Join fails | `1021` ChannelTokenUsed | The token has already been used; issue a new one |
| Join fails | `1032` SidNotFound | The session is no longer online (for example, reusing the same token after the process exited) |
| Join fails | `1002` HeaderInvalidAppId | Invalid AppID |
| Backend API call fails | `1003` HeaderInvalidSignature | Wrong signature; check the concatenation order and the AppKey |

For the full list of error codes, see [Server API · Error codes](/en/rtc/server-api/error-codes).

<Warning>
  **Issue a separate token for each client instance.** If you start two processes with the same token, the second one gets `1032`. When testing interoperability across devices, each one gets its own token.
</Warning>

***

## Related

* [Key concepts](/en/rtc/key-concepts)—channels, users, and tracks
* [Server API overview](/en/rtc/server-api/overview)—signing algorithm and request format