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

> The SMeetingError enum of the SMeeting Swift SDK: every case with its client code, how codes get the iOS 203 / macOS 205 prefix while server codes pass through, common causes of unauthorized, a recommended do-catch pattern, and which APIs never throw. Read when handling or troubleshooting errors.

The error type the SDK throws is `SMeetingError`, a semantic Swift enum that also provides an integer error code.

* Use `switch` to branch on meaning
* Use `error.code` to get the integer error code, handy for logs and support tickets
* Use `error.message` to get a plain-text description
* `error.localizedDescription` outputs `"<code>: <message>"`

***

### Error list

| Error | Client code | Description | Suggested handling |
| - | :-: | - | - |
| `notLoggedIn` | `1` | `您尚未登录meeting sdk` (You are not logged in to the meeting SDK) | Call `login(token:)` first |
| `tokenExpired` | `2` | `token已过期` (The token has expired) | Get a new token from your backend |
| `notInMeeting` | `3` | `您不在会议中` (You are not in a meeting) | Check when you call it; in-meeting APIs require `enterRoom` first |
| `unauthorized` | `4` | `您没有权限进行此操作` (You don't have permission for this operation) | Check the room policies and your own role; see below |
| `tokenInvalid` | `5` | `Token 格式无效` (Invalid token format) | Check your backend's issuing logic and whether the token was truncated in transit |
| `alreadyInMeeting` | `6` | `已在会议中，请先退出` (Already in a meeting; exit it first) | Call `exitRoom()` before entering a new meeting |
| `networkError(String)` | `7` | `网络错误: <detail>` (Network error: \<detail>) | Ask the user to check the network and retry |
| `deviceError(String)` | `8` | `设备错误: <detail>` (Device error: \<detail>) | Check whether the device is turned on and whether it's in use |
| `internalError(String)` | `9` | `内部错误: <detail>` (Internal error: \<detail>) | Troubleshoot using the associated string and logs |
| `apiError(code:message:)` | Server code | Business error returned by the server | Handle it by the server error code; `message` can be shown to the user directly |

***

### Error code format

`SMeetingError.code` returns the full, assembled error code:

* **Client errors** (those in the table above whose client code is less than 1000) get a platform prefix, forming a 6-digit number: the iOS prefix is `203`, and the macOS prefix is `205`
* **Errors passed through from the server** (`apiError` with a server code of 1000 or greater) are kept as-is, without a prefix

Examples:

| Scenario | iOS | macOS |
| - | - | - |
| `notLoggedIn` | `203001` | `205001` |
| `unauthorized` | `203004` | `205004` |
| Server returns `2001` | `2001` | `2001` |

This lets you tell at a glance whether an error was "stopped by the client itself" or "returned by the server."

***

### Common sources of `unauthorized`

This is the error you're most likely to run into, and it almost always comes from room policies:

| Call | Trigger condition |
| - | - |
| `requestOpenMic(...)` | The room has mute all on and members aren't allowed to unmute themselves, and you're not the host / a co-host |
| `requestOpenCamera(...)` | The room has camera off for everyone and members aren't allowed to turn them back on themselves, and you're not the host / a co-host |
| `requestShare(...)` | The room has sharing disabled, and you're not the host / a co-host |

We recommend graying out buttons in the UI in advance based on `RoomInfo`, rather than letting users tap them and then get an error.

***

### Recommended handling

```swift theme={null}
do {
    try await meeting.requestOpenMic()
} catch let error as SMeetingError {
    switch error {
    case .tokenExpired, .tokenInvalid, .notLoggedIn:
        await reLogin()
    case .unauthorized:
        showToast("The host has muted everyone")
    case .apiError(let code, let message):
        showToast(message)
        log("meeting api error \(code)")
    default:
        showToast(error.message)
        log(error.localizedDescription)
    }
} catch {
    // Errors thrown by the underlying audio and video layer
    log("\(error)")
}
```

Key points:

* Besides `SMeetingError`, the underlying audio and video layer may also throw its own error types (for example, capture failures or connection failures), so don't omit the catch-all `catch` branch
* Prefer `error.message` when showing messages to end users; use `error.localizedDescription` when writing logs, because it includes the error code
* `SMeetingError` conforms to `Equatable`, so you can compare it directly with a specific case

***

### APIs that don't throw

The following APIs are designed not to throw, so you can call them directly; repeated calls or calls in a mismatched state are safely ignored:

* `logout()`
* `exitRoom()`
* `closeMic()` / `closeCamera()` / `stopShare()`
* `disableIm()`
* `toggleRemoteAudioMute(_:)`
* `getRoomInfo()` / `getWhiteBoard()` / `getUsersInfo()` / `getUsersInfoList()` / `getRemoteVideoTrack(uid:desc:)` / `getDevices(kind:)`

***

### Related pages

* [Key concepts](/en/meeting/swift/key-concepts)
* [API reference - SMeetingEngine](/zh/meeting/swift/api-reference/SMeetingEngine) (Chinese)