> ## 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.

# Overview

> Basics of the SMeeting Server API: request method and format, base URL, request headers, the HMAC-SHA256 signing algorithm, and the response format. Read this before calling any SMeeting server endpoint.

The server API is called by your backend.

### Basic usage

Use the server endpoints that fit your business needs to control your meetings.

***

### Calling conventions

1. **Request method**: POST

2. **Request format**: `application/json`, encoded in UTF-8

3. **Base URL**: `https://{server-domain-or-IP}/meeting/{endpoint-path}`

4. **Request headers**

| Key | Description | Notes |
| - | - | - |
| appid | App ID | Required. `app_id` or `app-id` is also accepted, for languages or gateways that don't support underscores |
| nonce | Unique request ID, prevents duplicate submission | Required, a random 16-character string |
| timestamp | Unix timestamp in seconds | Required, accurate to the second, within ±5 minutes |
| signature | Signature value | Required, computed with HMAC-SHA256 as described below |

5. **Signing algorithm**

* **Step 1**: Build the string to sign by joining the app ID, `nonce`, `timestamp`, and the JSON string of the request body with `&`

```javascript theme={null}
// Assume appid=1 nonce=2 timestamp=3 and the request body is {}
appid=1&nonce=2&timestamp=3&{}
```

<Warning>
  **The field names in the string to sign must match the request header names you actually send.** You can use any of the three header names, but whichever you pick,
  the string to sign must start with that name—sending an `app_id` header while signing `appid=...` fails authentication.

  ```text theme={null}
  With the appid  header → appid=1&nonce=2&timestamp=3&{}
  With the app_id header → app_id=1&nonce=2&timestamp=3&{}
  ```

  Also, sign the request body as the **raw string**. It must be byte-for-byte identical to what you send (including whitespace and field order);
  don't serialize it again.
</Warning>

* **Step 2**: Compute HMAC-SHA256 over the string. The key is the `appkey` secret key.

```javascript theme={null}
HMACSHA256(key, stringToSign)
```

* **Step 3**: Convert the binary result to lowercase hexadecimal to get the `signature`

6. **Response format**: JSON

```json theme={null}
// On success, `data` contains the data
{
	"code": 0,
	"data": 123
}

// On error, `msg` is the error description ("认证失败" means "Authentication failed")
{
	"code": 10041,
	"msg": "认证失败"
}

// For list data, `_meta` contains the pagination info
{
	"code": 0,
	"data": [
		{"id": 123}
	],
	"_meta": {
		"totalCount": 5,
		"pageCount": 1,
		"currentPage": 1,
		"perPage": 20
	}
}
```

***