What the documents look like
A creator sales campaign depends on external creator fulfillment and commission settlement. Brand business teams, MCN organizations and creator agents work from four recurring documents: the creator cooperation agreement, the commission setting sheet, the sample shipment sheet and the livestream performance report. These materials sit across selected alliance records, creator marketplace data, creator history and store transaction details. Performance reports update per session; historical data updates weekly.
For order fulfillment and after-sales questions, the conversation log has to tie one campaign, one creator and one settlement document together. In practice this means the log identity comes from two fields: chatId identifies one conversation under one application, and dataId identifies one exchange inside that conversation. Checking fulfillment and after-sales records starts by locating the target conversation through chatId, then pulling a single exchange through dataId. Conversation sessions created through the page and sessions created through the API are separate populations. When run detail is needed, the request sets detail according to the official contract; in non-stream mode the result sits in responseData, and in stream mode the event field separates the output. The fields actually returned in the log define the checkable range. Business data that was not returned stays unknown.
Constraints at the conversation logs step
The conversation log is not an audit by itself. Reconciliation, retention and compliance requirements belong to a complete business plan implemented elsewhere; the existence of a log does not mean a compliance audit is complete. Test-mode and production calls may carry different identity fields, so inputs, history and returned content are checked separately.
Hypothetical paper exercise: A brand business team signs a creator cooperation agreement with one creator. The agreement names the counterparty as "Creator A" and the campaign as the "18 June 2025 session." The commission setting sheet states the commission rate for that session as "18%." The livestream performance report shows the session's transaction amount as "120,000 yuan." A draft sentence is now under review: "Creator A's commission for the 18 June 2025 session is 21,600 yuan." The check takes the counterparty and session from the agreement text, the rate from the commission setting sheet and the transaction amount from the performance report, and compares them under the same counterparty, same session and same field. When the product of the rate and the amount matches the draft sentence, that sentence gains material support. When any field is missing or the session does not match, the sentence remains pending verification.
Configuration and implementation checks
| Configuration item | Officially documented content | Check action on this page |
|---|---|---|
| chatId | A non-empty string uses that conversation; length under 250 | Check that the target conversation's chatId matches the business record |
| dataId | The ID of one exchange under a conversation | Pull a single exchange by dataId and check its content |
| detail | Returns intermediate values; non-stream results sit in responseData | Set it when run detail is needed and inspect responseData |
| source | source=api returns conversations created through the API | Check the conversation source and separate page conversations |
| responseChatItemId | When passed, stored in the database as the response message ID | Check the correspondence between the response message and the business record |
| variables | Module variables that replace [key] in input fields | Check that passed variables match the material fields |
Hypothetical trial starting point: set detail to true to obtain run detail, then compare against the response with detail set to false, to confirm whether responseData appears. This starting value is chosen because the documented contract ties responseData to the detail flag, and the comparison is between the two returned bodies.
Three common errors
- Merging page-entry conversations with API-created conversations in one count. Check input: take the conversation list with source=api and the conversation list from the page entry separately. Compare: the two sets of chatId values. Observable result: if the sets share a chatId, source separation did not take effect.
- Using chatId in place of dataId to locate a single exchange. Check input: multiple exchanges under the same chatId. Compare: the result of pulling one exchange by dataId against pulling all exchanges by chatId. Observable result: if the single result contains content from other exchanges, the locating field is wrong.
- Treating a field absent from the log as already retained. Check input: one response with detail=true. Compare: the fields actually present in responseData against the fields the business needs. Observable result: if a business field does not appear in the response, that field's status stays unknown.
How to verify the setup
- Input: the agreement text, the commission setting sheet and the performance report from the hypothetical sample. Compare: the counterparty, session, rate and amount in the draft sentence. Observable result: when all three fields match the draft sentence, the sentence gains support; when any field is missing, record it as pending verification.
- Input: a request that pulls a single exchange by dataId under one chatId. Compare: the returned content against the business record for that dataId. Observable result: when the content matches, the locating is correct; when content from another exchange appears, the locating failed.
- Input: two requests, one with detail set to true and one with detail set to false. Compare: the presence or absence of responseData in the two returned bodies. Observable result: responseData appearing with true and not appearing with false shows the field behaves per the contract; if neither response contains responseData, record it as not observed and do not infer a cause.
This page covers only creator sales campaigns, order fulfillment and after-sales questions, and conversation logs and audit. During operations handover, which materials, actions and requests sit at which authorization state must be clear; a retrieval result or a form does not count as authorization to execute.