> ## 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.
# Error code format
> How SRTC error codes are numbered across all platforms: how to tell from a code whether it came from the server or a client SDK and which platform, the platform type table, and where to look next. Read when you get an unfamiliar error code.
`0` means success; anything non-zero is an error.
Every error code has the structure **prefix + 3-digit specific code (001–999)**. Once you can read the prefix, you can immediately tell whether the error was **returned by the server** or **produced by a client SDK**, and **which platform** it came from—so you know where to start troubleshooting.
***
## How to read an error code
```text theme={null}
1 0 6 0 0 1
│ │ │ └─┴─┴── Specific code 001-999
│ │ └──────── Platform type: 6 = Web
└─┴────────── Product layer: 1 = SRTC
```
There are three cases:
| Digits | Source | Prefix | Example |
| - | - | - | - |
| 4 digits | Returned by the **server** | `1` | `1021` Token already used |
| 6 digits, 3rd digit is `0` | Client SDK, **common to all platforms** | `100` | `100008` Token invalid |
| 6 digits | Client SDK, **platform-specific** | `10` + platform type | `106001` Web: not currently in a channel |
***
## Platform types
The 3rd digit of a 6-digit error code indicates the platform:
| Type | Platform | SRTC prefix |
| :-: | - | - |
| 1 | Windows | `101` |
| 2 | Android phone | `102` |
| 3 | iOS phone | `103` |
| 4 | Linux C/C++ | `104` |
| 5 | macOS | `105` |
| 6 | Web (WebRTC) | `106` |
| 7 | Mini Program | `107` |
| 8 | Android set-top box | `108` |
| 9 | Android embedded | `109` |
| 80 | Server / embedded integration (C SDK) | `180` |
So `103002` reads as: SRTC layer + iOS + error number 002.
***
## Using it when troubleshooting
| Prefix | Meaning | Where to look first |
| - | - | - |
| `1xxx` | The server rejected the request | Check the signature, token, and channel state. See [Server API error codes](/en/rtc/server-api/error-codes) |
| `100xxx` | Common SDK error, the same on every platform | Usually parameters, initialization order, or network issues |
| `10Nxxx` | Error specific to that platform | See that platform's error code page |
| `180xxx` | Errors from the C SDK itself (server / embedded integration) | See [C SDK error codes](/zh/rtc/capi/error-codes) (Chinese) |
Full error code tables for each platform:
[Web](/en/rtc/web/error-codes) · [Android](/en/rtc/android/error-codes) · [Windows](/zh/rtc/windows/error-codes) (Chinese) · [Swift](/en/rtc/swift/error-codes) · [iOS](/zh/rtc/ios/error-codes) (Chinese) · [C](/zh/rtc/capi/error-codes) (Chinese)
**Read the C SDK at two levels.** Its **API return values** are simple status values such as `0 / -1 / -2 / -3 / -4`; they only express the result of the call and carry no reason. The actual reason is written to the log, which contains both the SDK's own `180xxx` codes and `1xxx` codes passed through from the server. See [C SDK error codes](/zh/rtc/capi/error-codes) (Chinese).
Don't branch on error **messages**—messages change between versions; error codes don't.
***
## Difference from SMeeting
Same rules, only a different product layer number: SRTC uses `1`, SMeeting uses `2`.
If you use SMeeting, you see both kinds of error codes: `2xxxxx` come from the meeting layer, and `1xxxxx` come from the underlying SRTC (passed through unchanged by the meeting layer to help you locate the problem). See [SMeeting error code format](/en/meeting/error-codes).