[DOC]: inconsistent request body for callbackBeforeSendGroupMsgCommand and callbackAfterSendGroupMsgCommand(recvID vs groupID)

[CyberCaelum]

Documentation Updates

The following callbacks have inconsistent request body definitions across different documentation pages. Two correct pages (using groupID) and two incorrect pages (using recvID) have been identified:

1. callbackBeforeSendGroupMsgCommand

Status	URL	Key Difference
Correct	https://doc.rentsoft.cn/zh-Hans/restapi/webhooks/group/sendGroupMsgBefore	Uses groupID (correct for group messages)
Inconsistent	https://doc.rentsoft.cn/zh-Hans/restapi/webhooks/msg/sendGroupMsgBefore	Uses recvID (inappropriate for group messages)

2. callbackAfterSendGroupMsgCommand

Status	URL	Key Difference
Correct	https://doc.rentsoft.cn/zh-Hans/restapi/webhooks/group/sendGroupMsgAfter	Uses groupID (correct for group messages)
Inconsistent	https://doc.rentsoft.cn/zh-Hans/restapi/webhooks/msg/sendGroupMsgAfter	Uses recvID (inappropriate for group messages)

For each callback, the incorrect version (under /msg/ path) should be removed or corrected to match the correct version (under /group/ path), ensuring the request body uses groupID instead of recvID for group‑message contexts.

Motivation

These inconsistencies are misleading for developers integrating OpenIM callbacks.

• If a developer follows the version with recvID, they will expect a field that is not relevant for group messages and may implement incorrect logic.
• The correct field for group‑message callbacks is groupID, as shown in the other version.
• The same mistake appears in both the “before send” and “after send” callbacks, which doubles the risk of integration errors.

Aligning both descriptions will reduce confusion and ensure developers build correct integrations.

Suggested Changes

I propose the following changes:

1. For callbackBeforeSendGroupMsgCommand

   • Remove or correct the version that uses recvID.
   • Keep the version that uses groupID as the authoritative description.

2. For callbackAfterSendGroupMsgCommand

   • Similarly, ensure the request body uses groupID instead of recvID (if the same inconsistency exists).
   • Confirm that the request example includes groupID and not recvID.

Current inconsistent fields comparison (for both callbacks):

Field	Incorrect version	Correct version
Recipient identifier	recvID (user ID)	groupID (group ID)
Presence of groupID	Missing	Present
Presence of recvID	Present	Missing

Additional Information

None