Live/im/api/en

跳转到: 导航, 搜索

目录

Overview

One of the cooperation mode between weibo and the third-party that access to weibo is server-side synchronization.This mode means doing message synchronization between live interactive system of weibo and interactive system of the third-party to implement message sharing. Send message interface and pull message interface(active pull and callback pull)can synchronize third-party messages to weibo.

Post Comments

Description

Post comment of the users to weibo live-im system.


URL

https://api.weibo.com/2/liveim/message/sync.json [POST]


Support Formats

JSON


Authorization

Required. More details of login authorization, Please refer to this WIKIHow to login to authorization


Request parameter

Parameter field Requires Field Type Field description
access_token true string Required parameters when using OAuth authorization mode,obtained after OAuth authorization
room_id true string room id
ts true long Timestamp(The number of milliseconds from 1970-01-01 00:00:00),cannot delay more than 2min
msg_type true int message types, see message types
content true string Message content
uid true long sender ID
nickname true string Sender nickname
avatar true string sender avatar url
sign true string The result of signing all the parameters other than sign ,See signature algorithm
extension false string message extension field see (json object format, the default is empty json object)
offset false long the time offset between sending message and the start of the live,unit:ms.If not pass, or pass the negative, do 0 process,indicating that the current message is not displayed when playing back.


Return result

//Successful return

{
    "error_code":0,    //0 indicates success,while others mean failed. Need to see the error message
    "error_msg":""
}


//Failed to return

{
    "error_code": 91XX,
    "error_msg": "xxxxxxxxx"
}

Receive Comments-Pull Mode

Description

This interface allows the third-party pull room messages from weibo live interactive system.After the third-party initiates the request,the interface will push the latest message in the room continuously as long as the connection is not broken.If the connection is disconnected accidentally,the message will continue to be pushed from the last disconnected position as long as the cumulative number of messages before the reconnection does not exceed the agreed threshold.


URL

https://api.weibo.com/2/liveim/message/pull.stream [GET]


Support Formats

JSON


Authorization

Required. More details of login authorization, Please refer to this WIKI How to log in to authorization


Request parameter

Parameter field Requires Field Type Field description
access_token true string Required parameters when using OAuth authorization mode,obtained after OAuth authorization
room_id true string room id

Return Result

The return message is pushed in JSON mode, and the data structure is pushed as follows. Each message is a separate JSON-OBJECT.

//Successful return

{
    "error_code":0,    //0 indicates success,while others mean failed. Need to see the error message
    "error_msg":"",
}
{
    // message body. See Annex [Data structure / message body]
}
{
    // message body.
}
...


//Failed to return

{
    "error_code": 91XX,
    "error_msg": "xxxxxxxxx"
}

about error return values and error codes, seeError Code Definitions

Receive Comments-Callback Mode

Description

If the third-party uses HTTP Callback mode to accept weibo messages,the third-party needs to provide an interface similar to [send message interface]. Requires the same parameters and return values as that interface.


URL

customize by the third-party


Support format

JSON


HTTP request mode

POST


Authorization

Required. More details of login authorization, Please refer to this WIKIHow to log in to authorization


Request parameter

Parameter field Requires Field Type Field description
source true string AppKey applied when applying for application,When calling an interface, it represents the unique identity of the application(This parameter is not required when using OAuth authorization mode)
room_id true string room id
ts true long Timestamp(The number of milliseconds from 1970-01-01 00:00:00)
msg_type true int Message Type 1 - Comment Message 2 - Praise message
content true string Message content
uid true long sender ID
nickname true string sender nickname
avatar true string sender avatar url
sign true string The result of signing all the parameters other than sign ,Seesignature algorithm
extension false string message extension fieldsee(json object format, the default is empty json object)
offset false long the time offset between sending message and the start of the live,unit:ms.If not pass, or pass the negative, do 0 process,indicating that the current message is not displayed when playing back.


Return result

//Successful return

{
    "error_code":0,    //0 indicates success,while others mean failed. Need to see the error message
    "error_msg":""
}


//Failed to return

{
    "error_code": 91XX,
    "error_msg": "xxxxxxxxx"
}

Signature Algorithm

Input:

- the list of key-value pairs

- appsecret used to signature


Output:

Signature Result String


Algorithm:

- Each of the key-value pair composes a string follows key=value format,each string is sorted by the dictionary order of the key(key is not the same),then a semiangle sign "&" is used to form a string.

- The string is encoded in UTF-8 to get a byte sequence input,the secret string is encoded by UTF-8 to generate a byte sequence as the key,the byte sequence of the hash value is calculated in the form of hmac-md5,the hash-value byte sequence uses URL-safe-Base64 encoding,then take the 6th to 16th characters as the result output.


Algorithm Example:

Assume that the input is:
kv-pair: {"a":"1", "c":"jerry", "b":"tom"}
appsecret:  123456
the concatenated string is:
a=1&b=tom&c=jerry
hmac-md5("a=1&b=tom&c=jerry",123456)
byte array output:[-117, -27, -78, -5, 73, 68, -64, -50, 4, 21, 16, -55, -55, -39, -31, -15]
converted to URL-safe base64 string:i-Wy-0lEwM4EFRDJydnh8Q==
take the 6th to 16th characters(initial bit is 0), contains the 6th, does not contain the 16th, a total of 10 bits:lEwM4EFRDJ


Signature results:

lEwM4EFRDJ

Data Structure

Message Body

{
    "room_id":string,      // room id
    "room_sys_id": uint64, // room id (internal)
    "msg_type":int,        // Message type, see "Message Type Description"
    "mid":long,
    "sender_info":{
        // user information of the sender, see "User Information"
    },
    "content":string,      // message content
    "extension":string,    // The extended field of the message
    "offset": long,        // the offset of message time from the video start time,unit:ms
    "created_at":long   // Timestamp,the number of milliseconds from 1970-01-01 0:00:00 GMT
      //If there are other fields, these fields continue here,related fields See "Additional fields for each message type"
}

extension

For the message types 1 to 14, each kind of message will have some unique fields used to represent the business, these fields will appear in the sys field inside of the extension, the structure is as follows:

extension = {
    "sys": {
        // The fields that appear here are listed in "unique additional fields to each type".If the extra field list is empty, the "sys" field may not exist 
    },
    // "Other transparent fields"
}

unique additional fields to each type

chat message,msg_type=1
"msg_behavior":uint32  //the display behavior of message  0: Default 1. Barrage
  
praise message,msg_type=2
"praises_count":int    // Current total number of praise
"inc_praises":long     // the number of times that users point like 
  
banned,msg_type=4
"shut_info":{          // the users be banned
    "shutted_until":uint32  //the remaining time of the end of prohibition,unit:s
    "members":[              //User list that be banned
     {
       "uid":uint64          //the UID of the user that be banned
       "user_system":string  //the system that the banned user belongs to 
     }
   ]
}
  
room change,msg_type=11
"live_status":int      // Indicates the status of the live broadcast
"room_info": {
    // Room information body, see "room information"
}
  
join room and exit room,msg_type=12
"exit_or_enter_room":int  // 0:exit 1:join
"room_info": {
    // Room information body, see "room information"
}
  
add and delete administrator,msg_type=14
"admin_info":{            // information of users that be added or deleted
    "uid":uint64              //UID of the administrator
    "user_system":string      //the system that the administrator belongs to 
    "type":int               //Operation Type 1:Add 2:Delete
}

Live Interface

Please refer tolive interface documentation

Message Type

   1 - chat message
   2 - praise message
   3 - light the anchor message
   4 - banned message
   6 - announcement message
   7 - share live messages
   8 - focus on the anchor message
   11 -live change message (any change in room status will be pushed)
   12 - join / exit room message
   13 - reward message
   14 - administrator change message
   100 - customize message type

Error code definition

error code error description
9101 authentication failed
9102 internal error
9103 data format error
9104 the message contains spam
9105 already exists
9106 data is not legal.the point that unlike 9103 : 9103 is the data format error, such as a int parameter should be passed but passed a string can not be resolved into int. And the current error code indicates that the data format itself is not a problem, but is an illegal data, such as ID corresponding entity does not exist.
9107 room is not allowed to speak
9108 user does not exist
9109 room does not exist
9110 token parse error
9111 room status is not correct
9112 the user is banned
9113 the current operation is not allowed
1019 the current operation is not supported