Channel Management REST API
In addition to the Voice/Video SDK integrated into the app client, Agora provides RESTful APIs for channel management, with which you can manage users in the channel and query channel statistics at the app server.
This page provides detailed help for the Agora Channel Management RESTful APIs.
Basic information
This section provides basic information about the Agora Channel Management RESTful APIs.
Domain
All requests are sent to the domain name: api.agora.io
. See Ensure service reliability for alternate domain names.
Data format
The Content-Type
field in all HTTP request headers is application/json
. All requests and responses are in JSON format. All request URLs and request bodies are case-sensitive.
Authentication
The Agora Channel Management RESTful APIs only support HTTPS. Before sending HTTP requests, you must generate a Base64-encoded credential with the Customer ID and Customer Secret provided by Agora, and pass the credential to the Authorization
field in the HTTP request header. See HTTP authentication.
Call frequency limit
For each Agora account (not each App ID), the call frequency of each online channel statistics query API is no more than 20 queries per second, and the call frequency of each other API is no more than 10 queries per second. If you are frequency limited when calling the APIs, please see How can I avoid being frequency limited when calling Agora Server RESTful APIs to optimize API call frequency.
Banning user privileges
Creates a rule
Creates a rule of banning specified user privileges.
The user privileges (privileges
) that can be banned include the following:
-
join_channel
: Joining a channel. -
publish_audio
: Publishing audio. -
publish_video
: Publishing video.
The banning rule works based on the following three fields: cname
, uid
, and ip
.
When you set privileges
as join_channel
, the rule works as follows:
-
If you set
ip
, but notcname
oruid
, then all users with thisip
cannot join any channel in the app.Using
ip
as a filter field may incorrectly block users who should not be blocked, for example, in a scenario where multiple users share an IP address. -
If you set
cname
, but notuid
orip
, then no one can join the channel specified by thecname
field.Using
cname
as a filter field directly blocks the channel with thecname
. -
If you set
uid
, but notcname
orip
, then the user with the user ID cannot join any channel in the app. -
If you set
cname
anduid
, but notip
, then the user with the user ID cannot join the channel specified by thecname
field.
When you set privileges
as publish_audio
or publish_video
, the rule works as follows:
-
If you set
ip
, but notcname
oruid
, then the users with thisip
cannot publish audio or video in any channel of the app. -
If you set
cname
, but notuid
orip
, then no one can publish audio or video in the channel specified bythecname
field. -
If you set
uid
, but notcname
orip
, then the user with the user ID cannot publish audio or video inany channel of the app. -
If you set
cname
anduid
, but notip
, then the user with the user ID cannot publish audio or video inthe channel specified by thecname
field.
A user who is kicked out of a channel (that is when you set privileges
as join_channel
) receives one of the following callbacks based on their platform:
- Android: The
onConnectionStateChanged
callback reportsCONNECTION_CHANGED_BANNED_BY_SERVER(3)
. - iOS/macOS: The
connectionChangedToState
callback reportsAgoraConnectionChangedBannedByServer(3)
. - Web (3.x): The
Client.on("client-banned")
callback. - Web (4.x): The
Client.on("connection-state-change")
callback. - Windows:The
onConnectionStateChanged
callback reportsCONNECTION_CHANGED_BANNED_BY_SERVER(3)
. - Electron: The
AgoraRtcEngine.on("connectionStateChanged")
callback reports3
. - Unity: The
OnConnectionStateChangedHandler
callback reportsCONNECTION_CHANGED_BANNED_BY_SERVER(3)
. - React Native: The
ConnectionStateChanged
callback reportsBannedByServer(3)
. - Flutter: The
ConnectionStateChanged
callback reportsBannedByServer(3)
. - Cocos Creator: The
onConnectionStateChanged
callback reportsCONNECTION_CHANGED_BANNED_BY_SERVER(3)
.
Prototype
- Method:
POST
- Endpoint:
https://api.agora.io/dev/v1/kicking-rule
Request parameters
Request body parameters
Pass in the following parameters in the request body:
Parameter | Data type | Required/Optional | Description |
---|---|---|---|
appid | String | Required | The App ID of the project. You can get it through one of the following methods:vendor_key field in the response body. |
cname | String | Optional | The channel name. |
uid | Number | Optional | The user ID. Do not set it as 0 . |
ip | String | Optional | The IP address of the user. Do not set it as 0 . |
time | Number | Required | The time duration (in minutes) to ban the user. The value range is [1,1440]. Note 0 and 1 , Agora automatically sets the value to 1 .1440 , Agora automatically sets the value to 1440 .0 , the banning rule does not take effect. The server sets all users that conform to the rule offline, and users can log in again to rejoin the channel.time or time_in_seconds . If you set both parameters, the time_in_seconds parameter takes effect; if you set neither of these parameters, the Agora server automatically sets the banning time duration to 60 minutes, that is, 3600 seconds. |
time_in_seconds | Number | Required | The time duration (in seconds) to ban the user. The value range is [10,86430]. Note 0 and 10 , Agora automatically sets the value to 10 .86430 , Agora automatically sets the value to 86430 .0 , the banning rule does not take effect. The server sets all users that conform to the rule offline, and users can log in again to rejoin the channel.time or time_in_seconds . If you set both parameters, the time_in_seconds parameter takes effect; if you set neither of these parameters, the Agora server automatically sets the banning time duration to 60 minutes, that is, 3600 seconds. |
privileges | Array | Required | The user privileges you want to block. You can choose the following values: join_channel : String. Bans a user from joining a channel or kicks a user out of a channel.publish_audio : String. Bans a user from publishing audio. You can pass in both publish_audio and publish_video to ban a user from publishing audio and video.publish_video : Bans a user from publishing video. You can pass in both publish_audio and publish_video to ban a user from publishing audio and video. |
Request example
Request body
Response parameters
For details about possible response status codes, see the Response status codes table.
If the status code is not 200
, the request fails. See the message
field in the response body for the reason for this failure.
If the status code is 200
, the request succeeds, and the response body includes the following parameters:
Parameter | Type | Description |
---|---|---|
status | String | The status of this request. success means the request succeeds. |
id | Number | The rule ID. If you want to update or delete the rule, you need the rule ID to specify the rule. |
Response example
The following is a response example for a successful request:
Gets the rule list
Gets the list of all banning rules.
Prototype
- Method:
GET
- Endpoint:
https://api.agora.io/dev/v1/kicking-rule
Request parameters
Query parameters
Pass the following query parameters in the request URL:
Parameter | Type | Required/Optional | Description |
---|---|---|---|
appid | String | Required | The App ID of the project. You can get it through one of the following methods:vendor_key field in the response body. |
Response parameters
For details about possible response status codes, see the Response status codes table.
If the status code is not 200
, the request fails. See the message
field in the response body for the reason for this failure.
If the status code is 200
, the request succeeds, and the response body includes the following parameters:
Parameter | Type | Description |
---|---|---|
status | String | The status of this request. success means the request succeeds. |
rules | Array | The list of banning rules. This array consists of multiple objects. Each object contains the information on one banning rule and includes the following fields:
|
createAt | String | The UTC time when this rule is created. |
updateAt | String | The UTC time when this rule is updated. |
Response example
The following is a response example for a successful request:
Updates a rule
Updates the expiration time of a specified banning rule.
Prototype
- Method:
PUT
- Endpoint:
https://api.agora.io/dev/v1/kicking-rule
Request parameters
Request body parameters
Pass in the following parameters in the request body:
Parameter | Type | Required/Optional | Description |
---|---|---|---|
appid | String | Required | The App ID of the project. You can get it through one of the following methods:vendor_key field in the response body. |
id | Number | Required | The ID of the rule that you want to update. |
time | Number | Required | The time duration (in minutes) to ban the user. The value range is [1,1440]. Note 0 and 1 , Agora automatically sets the value to 1 .1440 , Agora automatically sets the value to 1440 .0 , the banning rule does not take effect. The server sets all users that conform to the rule offline, and users can log in again to rejoin the channel.time or time_in_seconds . If you set both parameters, the time_in_seconds parameter takes effect; if you set neither of these parameters, the Agora server automatically sets the banning time duration to 60 minutes, that is, 3600 seconds. |
time_in_seconds | Number | Required | The time duration (in seconds) to ban the user. The value range is [10,86430]. Note 0 and 10 , Agora automatically sets the value to 10 .86430 , Agora automatically sets the value to 86430 .0 , the banning rule does not take effect. The server sets all users that conform to the rule offline, and users can log in again to rejoin the channel.time or time_in_seconds . If you set both parameters, the time_in_seconds parameter takes effect; if you set neither of these parameters, the Agora server automatically sets the banning time duration to 60 minutes, that is, 3600 seconds. |
Request example
Request body
Response parameters
For details about possible response status codes, see the Response status codes table.
If the status code is not 200
, the request fails. See the message
field in the response body for the reason for this failure.
If the status code is 200
, the request succeeds, and the response body includes the following parameters:
Parameter | Type | Description |
---|---|---|
status | String | The status of this request. success means the request succeeds. |
result | Object | The result of the update:id : String. The rule ID.ts : String. The UTC time when the rule expires. |
Response example
The following is a response example for a successful request:
Deletes a rule
Deletes a specified banning rule.
Prototype
- Method:
DELETE
- Endpoint:
https://api.agora.io/dev/v1/kicking-rule
Request body parameters
The following parameters are required in the request body:
Parameter | Type | Required/Optional | Description |
---|---|---|---|
appid | String | Required | The App ID of the project. You can get it through one of the following methods:vendor_key field in the response body. |
id | Number | Required | The ID of the rule that you want to delete. |
Request example
Request body
Response parameters
For details about possible response status codes, see the Response status codes table.
If the status code is not 200
, the request fails. See the message
field in the response body for the reason for this failure.
If the status code is 200
, the request succeeds, and the response body includes the following parameters:
Parameter | Type | Description |
---|---|---|
status | String | The status of this request. success means the request succeeds. |
id | String | The ID of the rule that you want to delete. |
Response example
The following is a response example for a successful request:
Online channel statistics query
Gets the user status
Gets the status of a specified user.
This method checks if a specified user is in a specified channel, and if yes, the role of this user in the channel.
Prototype
- Method:
GET
- Endpoint:
https://api.agora.io/dev/v1/channel/user/property/{appid}/{uid}/{channelName}
Request parameters
Path parameters
Pass the following path parameters in the request URL:
Parameter | Type | Required/Optional | Description |
---|---|---|---|
appid | String | Required | The App ID of the project. You can get it through one of the following methods:vendor_key field in the response body. |
uid | Number | Required | The user ID. Note: This parameter does not support string user accounts. Ensure that you use the integer user ID. |
channelName | String | Required | The channel name. |
Request example
Request URL
Response parameters
For details about possible response status codes, see the Response status codes table.
If the status code is not 200
, the request fails. See the message
field in the response body for the reason for this failure.
If the status code is 200
, the request succeeds, and the response body includes the following parameters:
Parameter | Type | Description |
---|---|---|
success | Boolean | The state of this request:
|
data | Object | User statistics, including the following fields: in_channel : Boolean. Whether the user is in the channel. When the value of in_channel is false , all other fields are not returned . |
join
: Number. The Unix timestamp in seconds of when the user joins the channel. role
: Number. The role of the user in the channel:
0
: Unknown user role.1
: User, in a communication channel.2
: Host, in the channel.3
: Audience, in the channel.
platform
: Number. The platform of the user's device. Common return values include:1
: Android2
:iOS5
: Windows6
: Linux7
: Web8
: macOS0
: Others
Response example
The following is a response example for a successful request:
Gets the user list
Gets the list of all users in a specified channel.
The return list differs with the channel profile as follows:
- In
COMMUNICATION
profile, this API returns the list of all users in the channel. - In
LIVE_BROADCASTING
profile, this API returns the list of all hosts and audience members in the channel.
- Users in a channel must use the same channel profile; otherwise, the query results may be inaccurate.
- You can synchronize the online channel statistics either by calling this API or by calling the Gets the user status API. Compared with the Gets the user status API, this API requires a lower call frequency and has a higher query efficiency. Therefore, Agora recommends using this API to query online channel statistics.
Prototype
- Method:
GET
- Endpoint:
https://api.agora.io/dev/v1/channel/user/{appid}/{channelName}
Request parameters
Path parameters
Pass the following path parameters in the request URL:
Parameter | Type | Required/Optional | Description |
---|---|---|---|
appid | String | Required | The App ID of the project. You can get it through one of the following methods:vendor_key field in the response body. |
channelName | String | Required | The channel name. |
Response parameters
For details about possible response status codes, see the Response status codes table.
If the status code is not 200
, the request fails. See the message
field in the response body for the reason for this failure.
If the status code is 200
, the request succeeds, and the response body includes the following parameters:
Parameter | Type | Description |
---|---|---|
success | Boolean | The state of this request:true : Success.false : Reserved for future use. |
data | Object | User information, including the following fields:
|
Response example
The following is a response example for a successful request:
In COMMUNICATION
profile
In LIVE_BROADCASTING
profile
Gets the channel list
Gets the list of all channels under a specified project.
This API gets the channel list by page. In the request URL, you can specify the page number and the number of channels shown on the page. A successful request returns the channel list of the specified page according to the set page_size
.
- A channel appears repeatedly in different pages.
- A channel does not appear in any page.
Prototype
- Method:
GET
- Endpoint:
https://api.agora.io/dev/v1/channel/{appid}
Request parameters
Path parameters
Pass the following path parameters in the request URL:
Parameter | Type | Required/Optional | Description |
---|---|---|---|
appid | String | Required | The App ID of the project. You can get it through one of the following methods:vendor_key field in the response body. |
Query parameters
Pass the following query parameters in the request URL:
Parameter | Type | Required/Optional | Description |
---|---|---|---|
page_no | Number | Optional | The page number that you want to query. The default value is 0, that is, the first page. Note: The value of |
page_size | Number | Optional | The number of channels on a page. The value range is [1,500], and the default value is 100. |
Response parameters
For details about possible response status codes, see the Response status codes table.
If the status code is not 200
, the request fails. See the message
field in the response body for the reason for this failure.
If the status code is 200
, the request succeeds, and the response body includes the following parameters:
Parameter | Type | Description |
---|---|---|
success | Boolean | The state of this request: true : Success. false : Reserved for future use. |
data | Object | Channel statistics, including the following fields:
|
Response example
The following is a response example for a successful request:
Response status codes
Response status code | Description |
---|---|
200 | The operation is successful. |
400 | Bad request. |
401 | Unauthorized (incorrect App ID/Customer Certificate). |
403 | Forbidden. |
404 | The requested resource could not be found. |
415 | Unsupported media type. Make sure that you set Content-Type in Headers as application/json . |
429 | Too many requests. |
500 | Internal error of the Agora RESTful API service. |
Ensure service reliability
This section presents the overall strategy you use to ensure high availability of REST services.
Switch the domain name
To ensure high availability of REST services, Agora enables you to switch domain names when you experience service outage due to regional network failures. Take the following steps to set up and switch your domain name:
-
Set the primary domain name based on the location of your service server:
- If the DNS address of the service server is located in a country or region other than mainland China, set the primary domain name to
api.agora.io
. - If the DNS address of the service server is in mainland China, set the primary domain name to
api.sd-rtn.com
.
- If the DNS address of the service server is located in a country or region other than mainland China, set the primary domain name to
-
If your attempt to initiate a RESTful API request using the primary domain fails, set up your retry strategy as follows:
-
Primary domain retry: Retry using the same primary domain name.
-
Alternate domain retry:
- If the current primary domain name is
api.sd-rtn.com
, useapi.agora.io
as the alternate domain name. - If the current primary domain name is
api.agora.io
, useapi.sd-rtn.com
as the alternate domain name.
- If the current primary domain name is
-
Adjacent domain retry: If alternate domain retry fails, retry using the domain name adjacent to the current region.
For example, suppose your business server is located in Europe. You set the primary domain name to
api.agora.io
, and the business server resolves the primary domain name to Germany. Germany is located in central Europe (api-eu-central-1.agora.io
). The domain name table shows that the adjacent area is West Europe. Use theapi-eu-west-1.agora.io
orapi-eu-west-1.sd-rtn.com
domain name to retry.
-
Precautions
Take the following precautions when setting up your retry strategy:
-
To avoid exceeding the QPS limit with retry requests, best practice is to use a back-off strategy. For example, wait 1 second before you retry for the first time, wait 3 seconds before retrying the second time, and wait 6 seconds before retry a third time.
-
If the request fails because of a network problem rather than a DNS domain name resolution problem, skip alternate domain retry and proceed to adjacent domain retry.
-
Before switching to the region domain name, ensure that the REST services you wish to use, for example, cloud recording or channel management, are deployed in that region.
Domain name table
The following table shows the primary and region domain names for various regions.
Primary domain name | Region domain name | Region |
---|---|---|
api.sd-rtn.com | api-us-west-1.sd-rtn.com | Western United States |
api-us-east-1.sd-rtn.com | Eastern United States | |
api-ap-southeast-1.sd-rtn.com | Southeast Asia Pacific | |
api-ap-northeast-1.sd-rtn.com | Northeast Asia Pacific | |
api-eu-west-1.sd-rtn.com | Western Europe | |
api-eu-central-1.sd-rtn.com | Central Europe | |
api-cn-east-1.sd-rtn.com | East China | |
api-cn-north-1.sd-rtn.com | North China | |
api.agora.io | api-us-west-1.agora.io | Western United States |
api-us-east-1.agora.io | Eastern United States | |
api-ap-southeast-1.agora.io | Southeast Asia Pacific | |
api-ap-northeast-1.agora.io | Northeast Asia Pacific | |
api-eu-west-1.agora.io | Western Europe | |
api-eu-central-1.agora.io | Central Europe | |
api-cn-east-1.agora.io | East China | |
api-cn-north-1.agora.io | North China |