|
1 | 1 | --- |
2 | | -title: Callback After Single Chat Message Recall |
| 2 | +sidebar_position: 1 |
| 3 | +title: Callback Description |
3 | 4 | hide_title: true |
4 | 5 | --- |
5 | 6 |
|
6 | | -# Callback After Single Chat Message Recall |
| 7 | +# 📞 Callback Description |
7 | 8 |
|
8 | | -## Description |
9 | | -The App backend can use this callback to receive requests for recalling a user's single chat message. |
| 9 | +📢 **OpenIM** offers powerful callback functionalities. When a specific event happens before or after a process, OpenIMServer proactively sends an HTTP/HTTPS request to the APP’s business server. This allows the APP’s business server to intervene in the subsequent processing of that event or to perform data synchronization based on the callback. |
10 | 10 |
|
11 | | -## Important Notes |
12 | | -- To enable this callback, configure the callback URL and activate the corresponding protocol switch. For configuration details, see the [Callback Introduction](../introduction) document. |
13 | | -- The callback direction is from OpenIMServer to the App backend as an HTTP/HTTPS POST request. |
14 | | -- The App backend must respond to this request within the specified timeout. |
| 11 | +## 📑 Callback Classification |
15 | 12 |
|
16 | | -## Scenarios that Trigger This Callback |
17 | | -- An App user recalls a single chat message through the client. |
18 | | -- An administrator recalls a single chat message through the `admin_msgwithdraw` REST API. |
| 13 | +Callbacks are divided into two main types based on the timing of their processing: |
19 | 14 |
|
20 | | -## Timing of Callback |
21 | | -- After the single chat message has been successfully recalled. |
| 15 | + • 🚫 **Callbacks Before the Event Occurs**: These “before” type callbacks allow the APP’s business server to intervene in the event handling process. For example, you can implement sensitive word filtering for messages. OpenIMServer determines subsequent steps based on the callback response. |
| 16 | + • 📤 **Notifications After the Event Occurs**: These “after” type callbacks are mainly used to notify the APP’s business server for data synchronization. For example, when a user joins a group. In this case, OpenIMServer ignores the callback’s return values and error codes. |
22 | 17 |
|
23 | | -## Interface Description |
| 18 | +## ⚙️ Configuration Description |
24 | 19 |
|
25 | | -### Example Request URL |
26 | | -The `CallbackCommand` here is: `callbackBeforeAfterMsgCommand` |
27 | | - |
28 | | -```plaintext |
29 | | -{WEBHOOK_ADDRESS}/callbackBeforeAfterMsgCommand?contenttype=json |
30 | | -``` |
31 | | - |
32 | | -### Example Request Package |
33 | | -```json |
34 | | -{ |
35 | | - "callbackCommand": "callbackBeforeAfterMsgCommand", |
36 | | - "conversationID": "si_u1_u2:0", |
37 | | - "seq": 10, |
38 | | - "userID": "user456" |
39 | | -} |
| 20 | +```yaml |
| 21 | +url: http://127.0.0.1:10006/callbackExample |
| 22 | +beforeSendSingleMsg: |
| 23 | + enable: false |
| 24 | + timeout: 5 |
| 25 | + failedContinue: true |
40 | 26 | ``` |
41 | 27 |
|
42 | | -### Request Package Field Descriptions |
| 28 | + • url: The APP business server callback address, supports HTTP/HTTPS |
| 29 | + • enable: Whether to enable the callback, true for enable |
| 30 | + • timeout: Response timeout in seconds |
| 31 | + • failedContinue: Whether to continue the process if the callback times out or if the API fails. Generally effective for before type callbacks. true means to continue execution. |
43 | 32 |
|
44 | | -| Field | Type | Description | |
45 | | -|------------------|--------|-----------------------------------------------| |
46 | | -| callbackCommand | string | Callback command for recalling a single chat message | |
47 | | -| conversationID | string | Conversation ID | |
48 | | -| seq | string | Message sequence number | |
49 | | -| userID | string | User ID of the message sender | |
| 33 | +## 🔄 Callback Protocol |
50 | 34 |
|
51 | | -## Example Response Package |
| 35 | +**OpenIMServer** uses a third-party callback mechanism based on HTTP/HTTPS protocol. When initiating a callback request, OpenIMServer sends a POST request to notify the APP’s business server. The specifics of these requests are directly included in the request body. |
52 | 36 |
|
53 | | -### Success Response |
54 | | -The backend confirms successful processing of the recall request. |
| 37 | +### Sample Request URL |
55 | 38 |
|
56 | | -```json |
57 | | -{ |
58 | | - "actionCode": 0, |
59 | | - "errCode": 0, |
60 | | - "errMsg": "", |
61 | | - "errDlt": "", |
62 | | - "nextCode": 0 |
63 | | -} |
| 39 | +```plaintext |
| 40 | +{WEBHOOK_ADDRESS}/callbackCommand?contenttype=json |
64 | 41 | ``` |
65 | 42 |
|
66 | | -## Response Package Field Descriptions |
| 43 | +### Request Parameter Description |
| 44 | + |
| 45 | +|Parameter | Description | |
| 46 | +|-----------------|------------------------------------------------------------| |
| 47 | +|{WEBHOOK_ADDRESS} | The url field in webhooks.yml, domain or hostname, for example: http://127.0.0.1:10006/callbackExample| |
| 48 | +|callbackCommand | The callback command, refer to each callback method’s description for details| |
| 49 | +|contenttype | The request input type, json| |
| 50 | + |
| 51 | +### Header |
67 | 52 |
|
68 | | -| Field | Value | Description | |
69 | | -|---------------|-------------------------------|-------------------------------------------------------| |
70 | | -| actionCode | 0 | Indicates whether the callback was successfully executed. `0` means success. | |
71 | | -| errCode | 0 | Custom error code; `0` to ignore the callback result. | |
72 | | -| errMsg | "An error message" | Simple error message for the custom error code | |
73 | | -| errDlt | "Detailed error information" | Detailed error message | |
74 | | -| nextCode | 1 | Next step directive, `1` to halt further action if `actionCode` is `0` | |
| 53 | +|Header Name |Example Value| Required |Type |Description| |
| 54 | +|-----------------|-----------------|-----------------|-----------------|-----------------| |
| 55 | +|operationID| 123456| Yes |string| Used for global link tracking, recommended to use timestamps, unique in each request| |
0 commit comments