What the documents look like
Seller ratings work handles consumer feedback that arrives after order fulfilment is complete, and it stays separate from promotional pricing decisions. The working materials for this category are negative-review handling records, experience-score detail sheets, service diagnostic reports, and rectification ledgers, with update frequency described as daily or weekly. The conversation logs and audit step examines the session and dialogue records produced during after-sales question answering, and whether those records can be matched against the business materials.
A session is identified by chatId and a dialogue by dataId. These sit at different levels, so any reconciliation must pull data under the same appId and the same chatId. When intermediate run values are needed, detail is set according to the official contract, and non-streaming results are held in responseData. Business fields the interface does not return cannot be assumed to be fully retained. The presence of a log does not by itself complete a compliance audit; reconciliation, retention, and compliance requirements are carried out separately by a full business plan.
Constraints at the conversation logs step
The conversation logs and audit step is bounded by several documented conditions. The chatId must be unique and shorter than 250 characters, and it is normally the dialogue-box ID of the caller's own system. When chatId is a non-empty string, the system takes the session from the FastGPT database and uses the last item of the messages array as the user question, ignoring the remaining messages. When chatId is absent, FastGPT context is not used and context is built entirely from the supplied messages. The responseChatItemId, if passed, becomes the response message ID and must be unique under the current chatId. The model and temperature fields passed in the request body have no effect, because the orchestration decides them. Actual token consumption is not returned unless detail is set to true, in which case the tokens values inside responseData are calculated manually.
Interactive nodes change the flow. When a workflow reaches an interactive node it returns immediately. With detail=true and stream=true, the interactive configuration is read from data.interactive under event=interactive; with stream=false, it is read from elements inside choices[].message.content. The interactive object returned to an external caller is a display configuration containing type and params only. Internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs, and nodeResponseId are not returned. When an internal children, loop, or tool wrapper interaction is hit, the interface returns the deepest user-facing interactive node.
Continuing after an interaction uses the same interface. For a user selection, the chosen result is passed directly in messages. For form input, the entered content is serialized as an object into a string and placed in messages, with object keys matching the form keys, and the chatId must remain consistent.
Session management distinguishes sources. The history list endpoint accepts source=api to return sessions created through the API and does not return sessions from the page. Clearing an application's sessions through the API key clears only sessions created through the API key, and does not clear sessions from online use, share links, or other sources. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination.
Configuration and implementation checks
| Configuration item | Purpose on this page | Check method |
|---|---|---|
| appId | Locate the target application | Matches the appId returned in the session list |
| chatId | Locate the target session | Shorter than 250 characters, matched one-to-one against business records |
| dataId | Locate the target dialogue | Unique under the corresponding chatId |
| detail | Obtain intermediate run values | Set per the official contract, then inspect responseData |
| responseChatItemId | Mark the response message ID | Unique under the same chatId |
| loadCustomFeedbacks | Read custom feedback | Set as needed, then verify the returned fields |
These rows describe documented settings and implementation checks tied to this page's documents. They are not a quota, and no default values, limits, units, menus, or global switches are asserted beyond what the official contract states.
Three common errors
- Mixing the chatId from a session list with the dataId of a dialogue. Input: the session list returns chatId C-001. Comparison: compare against the dialogue identifier in the business record. Observable result: if the business record carries a dataId, the chatId cannot stand in for that identifier.
- Inferring record ownership from a similarity score. Input: a quoteList entry with score 0.89. Comparison: compare against the business ownership field. Observable result: the score does not constitute a permission or entity filter, and ownership still requires verification.
- Writing a replied status as closed. Input: the source text states "status is replied". Comparison: compare against the draft sentence "after-sales handling is complete and closed". Observable result: the closing action and its time are not stated, so the draft sentence is unsupported.
How to verify the setup
Hypothetical paper exercise sample, clearly labelled and not drawn from any real customer or record. Material for reconciliation, two source sentences: "Handling record: after-sales inquiry for order A has been replied to, handler Zhang Ming, status is replied." "Session record: chatId is C-001, dataId is D-009, the agent reply content is the return-and-exchange explanation." Draft sentence to be judged: "This order has completed after-sales handling and is closed."
- Input: the two source sentences and the one draft sentence. Comparison: the closing action asserted by the draft sentence against the status stated in the material. Observable result: the material does not state a closing, so the draft sentence is judged unsupported.
- Input: chatId C-001 and dataId D-009. Comparison: the two levels against the fields of the business record. Observable result: if the business record carries only a dataId, the chatId cannot substitute for that identifier.
- Input: the module fields returned in responseData. Comparison: against the retention fields required by the business plan. Observable result: missing fields are recorded as gaps, and retention is not presumed.
These checks state expected outcomes and do not claim that any test, deployment, approval, refund, or other business action has taken place. Where evidence is missing, it remains missing.