Messaging REST API
You use this API to send messages to a user or a channel.
Authentication
For basic HTTP authentication, you can send peer-to-peer or channel messages with any user ID. For token authentication, you send peer-to-peer or channel messages with only the user ID used to generate the Signaling token.
If the messaging time delay from the server to the client must be less than 200 ms, Agora recommends that you use the Signaling SDK for Linux C++ or the Signaling SDK for Linux Java to send messages from the server to the client.
Basic authentication
You need to pass the basic HTTP authentication and put api_key:api_secret
in the Authorization
field of the HTTP header. For more information on how to generate the Authorization
field, see Secure authentication with tokens.
Token authentication
If you have already generated an Signaling Token on your server, you can use token authentication. You need to put the following information to the x-agora-token
field and the x-agora-uid
field when sending your HTTP request:
- The Signaling Token generated at your server.
- The uid you used to generate the Signaling Token.
Sample code
The following sample code shows how to implement token authentication in Java:
For more information about how to generate an Signaling Token, see Secure authentication with tokens.
Data format
All requests are sent to the host: api.agora.io
. See Ensure service reliability for alternate domain names.
- Request: See the examples in the following APIs.
- Response: The response content is in JSON format.
- Base URL:
https://api.agora.io/dev/v2/project/<appid>
'appid' is the App ID used by your project. All the request URLs and request bodies are case-sensitive.
Sends peer-to-peer message API (POST)
- Method: POST
- Access point:
/rtm/users/<user_id>/peer_messages
Sends a peer-to-peer message from the server. The user who sends the message does not have to log into Signaling.
Call limit
For each app ID, the maximum combined frequency of the Sends peer-to-peer message API and the Sends channel message API is 500 calls per second.
Call sequence
The following figure shows the process in which the server sends a peer-to-peer message to the Signaling SDK.
-
The receiver is online and
wait_for_ack
istrue
-
wait_for_ack
isfalse
Parameters
URL parameters
This API has the following URL parameters:
Parameter | Type | Description |
---|---|---|
user_id | String | Signaling user ID to send a peer-to-peer message. Must not exceed 64 characters in length and not be an empty string. This parameter supports the following characters:
As a URL parameter, the first character and the last character must not be a space. |
Query parameters
This API has the following query parameters:
Parameter | Type | Description |
---|---|---|
wait_for_ack | Boolean | (Optional) Whether the API returns the HTTP response after the Signaling receives the ack response from the receiver to indicate that the message is received. The default is false .
|
Request body parameters
This API has the following request body parameters:
Parameter | Type | Description |
---|---|---|
destination | String | Signaling user ID to receive a peer-to-peer message. Must not exceed 64 characters in length and not be an empty string. This parameter supports the following characters:
|
enable_offline_messaging | Boolean | The offline message feature will be deprecated. Agora recommends that you do not use it. (Optional) Whether to enable offline messages. The default is false .
|
enable_historical_messaging | Boolean | Whether to save as a historical message. The default value is false .
|
payload | String | Content of the peer-to-peer message. Must not be an empty string and not exceed 32 KB in length. |
Response body parameters
This API has the following response body parameters:
Parameter | Type | Description |
---|---|---|
result | String | Request result.
|
request_id | String | Unique ID to identify this request. |
code | String | Message status.
|
Request example
-
Request URL:
-
Content-type
isapplication/json;charset=utf-8
-
Authorization
is basic HTTP or token. See RESTful API Authentication. -
Request body:
Response example
The message has been sent:
The message has been received:
The receiver is offline:
Sends channel message API (POST)
- Method: POST
- Access point:
/rtm/users/<user_id>/channel_messages
Sends a channel message from the server. You can send a message to a channel without having to join it first.
Call limit
For each app ID, the maximum combined frequency of the Sends peer-to-peer message API and the Sends channel message API is 500 calls per second.
Parameters
URL parameters
This API has the following URL parameters:
Parameter | Type | Description |
---|---|---|
user_id | String | Signaling user ID to send a channel message. Must not exceed 64 characters in length and not be an empty string. This parameter supports the following characters:
As a URL parameter, the first character and the last character must not be a space. |
Request body parameters
This API has the following request body parameters:
Parameter | Type | Description |
---|---|---|
channel_name | String | Signaling channel name to receive a channel message. Must not exceed 64 characters in length and not be an empty string. This parameter supports the following characters:
|
payload | String | Content of the channel message. Must not be an empty string and not exceed 32 KB in length. |
Response body parameters
This API has the following response body parameters:
Parameter | Type | Description |
---|---|---|
code | String | Message status. "message_sent" : The message is sent. |
request_id | String | Unique ID to identify this request. |
result | String | Request result.
|
Request example
-
Request URL
-
Content-type
isapplication/json;charset=utf-8
-
Authorization
is basic HTTP or token. See Secure authentication with tokens. -
Request body:
Response example
Status code
Status code | Description |
---|---|
200 | The request is successful. |
400 | The request parameters are incorrect. Please check the parameters per the error message. |
401 | User authentication error. |
408 | No response from the server or the request times out. Please try again later. |
429 | Too many requests. |
500 | Internal server error. |
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 |