> ## 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.
# Whiteboard
> Authorize, check, and destroy whiteboards
## Get a whiteboard authorization code
`POST /server/v1/white-board/grant-code`
Authentication: required (see [Overview](/en/rtc/server-api/overview))
Get a whiteboard authorization code. A whiteboard is a collaborative board independent of channels; users who pass the same board
open the same whiteboard.
The typical flow is similar to the channel token: your backend checks permissions → calls this endpoint to get auth\_code and addr →
sends them to the client → the client combines them into \{addr}?code=\{auth\_code} and opens it (the whiteboard is an H5 page,
embedded with an iframe or WebView). The authorization code is valid for 1 hour and expires once connected; get a new one
every time the whiteboard is opened, and don't cache it.
A whiteboard is created automatically the first time it is authorized; you don't need to create it in advance.
Users in a channel have an easier route: the join response already includes a ready-made whiteboard URL (field
white\_board, whose authorization code is that user's sid), which you can embed directly without calling this endpoint. This endpoint is for
"people outside the channel also need the whiteboard" and "using the whiteboard independently of channels". For the full integration guide,
see the "Whiteboard" docs.
**Request parameters**
Board ID, with the same character set restrictions as channel names. A common practice is to use the channel name directly, so each channel maps to one whiteboard (up to 64 bytes; letters, digits, underscores (\_), and hyphens (-) only)
Example: `fire`
Third-party user ID, used to show collaborator cursors and operators (letters, digits, underscores (\_), and hyphens (-) only) (max length 100)
Example: `1001`
Third-party user name
Example: `Alice`
Network line. The value is a Chinese line name; leave empty to let the server choose
Example: `内网`
Server group
Request example:
```json theme={null}
{
"board": "fire",
"name": "Alice",
"net": "内网",
"sg": "",
"uid": "1001"
}
```
**Response parameters**
Whiteboard authorization code, issued to the client to open the whiteboard
Example: `wb-co63jg6g54hu3b0xhtie`
Whiteboard page URL; combine it with the authorization code as \{addr}?code=\{auth\_code}
Example: `https://api.example.com/white-board/`
Response example:
```json theme={null}
{
"code": 0,
"data": {
"addr": "https://api.example.com/white-board/",
"auth_code": "wb-co63jg6g54hu3b0xhtie"
}
}
```
***
## Check whether a whiteboard exists
`POST /server/v1/white-board/exist`
Authentication: required (see [Overview](/en/rtc/server-api/overview))
Check whether a whiteboard exists, that is, whether it has been created and not destroyed.
Use it to decide "is there still content on this board"—for example, whether to show an "Open whiteboard" entry,
or to confirm that a destroy has taken effect.
**Request parameters**
Board ID (up to 64 bytes; letters, digits, underscores (\_), and hyphens (-) only)
Example: `fire`
Request example:
```json theme={null}
{
"board": "fire"
}
```
**Response parameters**
Whether the whiteboard exists (created and not destroyed)
Response example:
```json theme={null}
{
"code": 0,
"data": {
"is_exist": false
}
}
```
***
## Destroy a whiteboard
`POST /server/v1/white-board/destroy`
Authentication: required (see [Overview](/en/rtc/server-api/overview))
Destroy a whiteboard. Content on the board is cleared and can't be recovered; users currently on the whiteboard are disconnected.
Whiteboards also have two automatic destroy paths; this endpoint is for cleaning up proactively before those happen (such as "Close whiteboard" during a call):
* When a channel is destroyed, the whiteboard with the same name is destroyed with it. A channel is destroyed automatically after 2 hours with no one in it, so a whiteboard used the recommended way
(board set to the channel name) also disappears 2 hours after everyone leaves. To keep whiteboard content
long term, don't use the channel name as board.
* A whiteboard with no writes for more than 25 hours is cleaned up by a scheduled job.
**Request parameters**
Board ID (up to 64 bytes; letters, digits, underscores (\_), and hyphens (-) only)
Example: `fire`
Operator ID, used for auditing
Example: `1001`
Operator name
Example: `Alice`
Request example:
```json theme={null}
{
"board": "fire",
"op_name": "Alice",
"op_uid": "1001"
}
```
**Response parameters**
`data` is null
Response example:
```json theme={null}
{
"code": 0,
"data": null
}
```
***