Skip to main content
如果你的诉求是「把会议能力挂到既有业务流程上」——一次招投标、一场评审、一个工单派发—— 而不是做一款会议产品，那么你不需要集成 SMeeting SDK，也不需要写会议界面。 会议客户端、用户体系、登录态我们都已经部署好了，你的后端只做三件事： 第 1 步在业务活动创建时做，第 2、3 步在用户点「进入会议」时做。 不需要预先注册用户。 换 token 时把 user_id 和昵称一起传过来，人不存在就现场建、 已存在就顺带更新资料。只有当你要在会议客户端里提供通讯录时，才需要额外做 批量同步用户。
这条路径和带 UI 极简对接的区别：那边是你拿走前端源码自己改界面、 自己部署；这边是连界面都用我们部署好的，你只在服务端拼一个 URL。

​
两组基地址

对接会用到两个前缀，域名相同：
标准部署下会议服务挂在 /meeting/ 网关前缀之下，别把这段前缀漏掉 —— 同域名的根路径 /server/v1/... 走的是 SRTC 音视频服务，请求发过去会找不到会议接口。下文各步骤只写接口路径（如 POST /server/v1/meet/create），实际请求时都要拼上 https://<你的域名>/meeting 这个基地址。如果你的环境是独立域名部署，前缀可能不同， 以我们提供的接入信息为准。
两者用同一组 app_id / app_key，鉴权方式也完全一致——app_id / nonce / timestamp / signature 四个请求头，HMAC-SHA256 签名，算法见 服务端 API 概览。签名代码写一份，两个前缀都能用。
app_key 只能待在你的后端。上面三步里，只有第 3 步的 URL 会到达浏览器， 它携带的是一次性的用户 token，不是密钥。

​
用什么认人

整条链路上认人只靠一个值：你的系统里的用户唯一标识。用户 ID、工号、身份证号、 手机号都行，只要在你那边唯一、且不会变。 所有接口里它都叫 user_id——换 token、同步、白名单，填的都是同一个值。
这个值一旦用过就不要再改。 它是认人的唯一依据，改了等于换了一个人， 原来的参会记录不会跟过来。
我们不再另外生成一套用户 ID，所以没有需要你保存的映射关系。

​
第 1 步：创建会议

完整参数见会议管理，这里只说极简对接关心的几个：
  • extend_info 是挂业务单据的地方。它是一个自由结构的对象，我们只存储和回传， 把招投标编号放进去，后面收到回调时就能反查到自己的业务
  • conferee_details 指定参会白名单，配合 attend_type: 3（邀请人员参会） 就能挡住无关的人。这里的人不需要预先存在：user_id 就是身份，只给 user_id、 系统里查不到这个人，他照样能进会。但那样白名单里这条是没有名字的，参会人列表要等他 自己入会才显示得出来，所以每条尽量带上 real_name 或 nickname —— 带了就顺手 把人建出来。
  • 谁是主持人由 creator 决定，联席主持人放 co_hosts（数组）。两者填的也是 user_id，与白名单里是同一个值，不需要先同步用户再换一个 ID 回来。 creator 不填，服务端不会把任何人标成主持人，这场会谁都拿不到会控权限，建会时记得带上
  • conferee_details 里的 role 一般不用传：用内置角色时它不生效，指定主持人 / 联席主持人 走上面两个字段。只有开了自定义角色的项目（比如招投标 要区分专家、见证人）才靠它给每个人定身份
  • meeting_type：1 即时会议、2 预约会议。预约会议必须给 plan_time 和 plan_dur
  • 要自动录像就加 auto_record: true，不用在业务里管录制启停，详见 云录制与直播接入指南
返回里的 room_no 是第 3 步要用的房间号，meeting_id 是后续所有会议接口的入参：
不要用 attend_type 为 2 或 4 的密码会议。 第 3 步的拉起地址不支持传密码， 用户落到会议页后还得手动输一次，极简对接的意义就没了。用 1（无限制）或 3（邀请人员参会）。

​
第 2 步：换免登录 token

用户在你的系统里点「进入会议」时，后端实时调一次：
人不存在就用这几个字段现场建，已存在就顺带更新。 所以你不必维护一份「哪些人同步过」 的账本，每次换 token 都把最新的昵称、头像带上即可，改了名字下次进会就生效。
只传 user_id 而这个人从没出现过时会报错——因为没有昵称，建出来的用户在会中没有名字。 带上 nickname 就行。
返回值直接就是一个 token 字符串：
有效期 7 天。建议每次拉起前重新签发，不要缓存下来复用——它等价于这个用户的登录态。

​
第 3 步：拉起会议页

把 token 和房间号拼成地址，让用户的浏览器打开它：
nickname 里如果有中文或特殊字符，记得做 URL 编码。 进入会议时麦克风与摄像头默认关闭，由用户自己在会中打开。

​
完整时序

回调怎么接、怎么验签见回调事件接入指南。 meeting_id 会随事件回传，用它反查你在 extend_info 里存的单据号。

​
批量同步用户

上面三步不需要它。只有当你希望用户在会议客户端里能翻通讯录、从人员列表挑人入会时， 才需要提前把人推过来。
请求体是一个数组，单次不超过 1000 条：
返回按 user_id 分成成功与失败两张表：
success 的键与值都是你传的 user_id，没有需要存下来的东西——建会时的 creator 和 co_hosts 直接填 user_id 即可。fail 的值是这条失败的原因。 重复同步同一个 user_id 是更新而不是新建，所以全量推和增量推都行。同一时刻只允许一个 同步任务在跑，并发调用会收到「频率过快 请稍候」。

​
组织结构的能力边界

department 是一个平铺的字符串，不是层级。多级部门树目前只能在管理后台用 Excel 导入（最多四级、单次 500 行），没有对应的 API。 所以如果你只是想让参会人看到「张三（招标一部）」，department 够用；如果你要把整棵 组织树同步过来供用户在通讯录里逐级点选，当前这条路径做不到，需要单独提。

​
另外两个可选接口

查用户与在线状态 —— POST /stm/srvapi/v1/member/info
返回里带 is_online，可以在你的界面上显示「张三 在线」。 清理离职用户 —— POST /stm/srvapi/v1/member/remove 入参同上。删除后该用户无法再换 token 进会。

​
什么时候该改用完整 SDK

这条路径的代价是界面不是你的。出现下面任何一条，就该考虑集成 SMeeting SDK：
  • 会议界面要用你自己的品牌、布局或交互
  • 会议要嵌在你的 App 内部，而不是跳出去一个网页
  • 需要在会中做业务联动，比如开标环节到点自动解除全员静音
各端的集成方式见左侧「iOS SDK」「Android SDK」等分组。两条路径的服务端接口是同一套， 先用极简对接跑通业务流程、之后再换 SDK 做界面，前面的对接不会白做。