Skip to main content
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. 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
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:
1

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

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, and every API after that will be much easier to follow.
3

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.

​
Choose your platform

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.

​
Typical call order

API names differ across platforms, but the flow is the same:
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.

​
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 before deciding which layer to integrate with.