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

# Quickstart

> The shortest path to integrating SRTC: who does what across your client, your backend, our SDK, and our server; the three things to do before you start; per-platform entry points; and the typical call order.

This page gives the shortest path to integrating SRTC. Understand the division of responsibilities first, then follow your platform's entry point.

***

## Who does what

An integration involves four roles: **two are yours, and two are ours**.

| Role | Owner | Responsibilities |
| - | - | - |
| **Your client** | You | UI and interaction: entry buttons, video layout, user list, button states. Audio and video capabilities come from embedding our SDK |
| **Your backend** | You | User system and business rules: who is a valid user, and who can join this channel. Calls our server API with the `AppKey` |
| **Our SDK** | Us | Capture, encoding and decoding, transport, signaling, state sync, event callbacks. It is a library that runs inside your client |
| **Our server** | Us | Media forwarding, session state, recording / live streaming / re-streaming, and the server API your backend calls |

Remember this boundary in one sentence: **we don't touch your user system, and you don't touch the media streams.**

* You don't need to register users with us—use the user IDs your system already has as `uid`
* Audio and video data doesn't pass through your servers—clients connect directly to our media service, so your bandwidth bill doesn't grow because of calls

```mermaid theme={null}
sequenceDiagram
    participant FE as Your client (embeds SRTC SDK)
    participant BE as Your backend
    participant SRTC as SRTC service

    FE->>BE: 1. User requests to join a channel
    Note over BE: 2. Your business rules:<br/>can they join, and with what identity
    BE->>SRTC: 3. Call the server API for a token<br/>(signed with AppKey)
    SRTC-->>BE: 4. Return token
    BE-->>FE: 5. Deliver token
    FE->>SRTC: 6. SDK joins the channel with the token
    SRTC-->>FE: 7. Audio/video up and down, user join/leave events
    SRTC->>BE: 8. (Optional) Event callbacks: who joined or left, recording finished
```

Across the whole flow, **your backend "issues the key" and your client "uses the key"**. Media goes through us; business decisions stay with you.

***

## Before you start

Complete these three things in order, then go to your platform's docs:

<Steps>
  <Step title="Create an app">
    Get an **AppID** and **AppKey**. The AppKey is a server-side secret key and must never be put in a client—see [Token and authentication](/en/rtc/token).
  </Step>

  <Step title="Understand the model">
    SRTC has only three objects: channel, user, and track. It has no user system and no business rules. Spend five minutes reading [Key concepts](/en/rtc/key-concepts), and every API after that will be much easier to follow.
  </Step>

  <Step title="Get token issuance working">
    Step 3 in the diagram above is **the only server code you must write** in the whole integration: after verifying your own user's identity, sign a request with the AppKey to call our grant endpoint, and return the token to the client.

    While debugging, you can generate a temporary token in the developer console to get the client working first; production must issue tokens from your backend. For how to wrap this on the backend and where to draw permission boundaries, see [Reference backend implementation](/en/rtc/server-api/server-demo).
  </Step>
</Steps>

***

## Choose your platform

| Platform | Entry point |
| - | - |
| Web | [Integration](/en/rtc/web/integration) · [Quickstart](/en/rtc/web/quickstart) |
| Android | [Integration](/en/rtc/android/integration) · [Quickstart](/en/rtc/android/quickstart) |
| Windows | [Integration](/zh/rtc/windows/integration) (Chinese) · [Quickstart](/zh/rtc/windows/quickstart) (Chinese) |
| Swift (iOS / macOS) | [Integration](/en/rtc/swift/integration) · [Quickstart](/en/rtc/swift/quickstart) |
| iOS (Objective-C) | [Integration](/zh/rtc/ios/integration) (Chinese) · [Quickstart](/zh/rtc/ios/quickstart) (Chinese) |
| C (server / embedded) | [Integration](/zh/rtc/capi/integration) (Chinese) · [Quickstart](/zh/rtc/capi/quickstart) (Chinese) |
| Python (server-side AI) | [Integration](/en/rtc/python/integration) · [Quickstart](/en/rtc/python/quickstart) |
| Server | [Server API](/en/rtc/server-api/overview) |

<Note>
  For WeChat Mini Program, we recommend embedding a page built with the Web SDK via `<web-view>`, so one codebase covers both browsers and Mini Programs. See [Web SDK integration](/en/rtc/web/integration).
</Note>

***

## Typical call order

API names differ across platforms, but the flow is the same:

```text theme={null}
Initialize the SDK
  → Set event callbacks     (must be before joining the channel, or you miss early events)
  → Join the channel (with the token)
  → Capture and publish local tracks
  → Subscribe to remote tracks and render them
  → Leave the channel → Release resources
```

<Tip>
  The most common pitfall is **registering callbacks after joining the channel**—you then miss the batch of "users already in the channel" events; the symptom is that you can't see anyone else after joining. Every platform's quickstart shows the correct order.
</Tip>

***

## Common questions about the boundary

**Does audio and video go through my servers?** No. Clients connect directly to our media service; your backend only handles authentication and business decisions.

**Do users need to register with you first?** No. We don't store your user data; use your own user ID as the `uid`.

**What happens if the AppKey is in the frontend?** Anyone who gets it can issue tokens for any user identity, remove users, and destroy channels. It must stay on the server.

**Who enforces permission rules?** You. We only trust what's written in the issued token; "can this person join this channel" is the decision your backend makes in step 2.

***

## If you're building a meeting product

Host, raise hand, mute all, and waiting room are not part of SRTC; you have to implement them yourself. If your product is a meeting product to begin with, read [Choosing SRTC or SMeeting](/en/choose) before deciding which layer to integrate with.