What the documents look like
Seller ratings and experience-score maintenance draws on platform experience scores, marketplace service indicators, after-sales review records, and customer-service systems. The update frequency is daily or weekly. The working documents include negative-review handling records, experience-score breakdowns, service diagnostic reports, and rectification ledgers. Inventory procurement and supplier materials sit inside the after-sales fulfilment stage: purchase orders, supplier delivery records, and inventory ledgers.
In the HTTP integrations step, these materials travel as request bodies or variable values into an external system. The HTTP module sends a request to a configured address; Params, Headers, and Body can each reference variables through {{}}, and the URL can also reference variables. The interface itself does not judge whether a material is authentic. It passes fields.
Constraints at the HTTP integrations step
The HTTP module sends a request to a target address. Params carry path parameters, Headers carry request headers, and Body carries the request payload, which takes effect only under the relevant request types. Variables can come from global variables, system variables, or the outputs of preceding nodes. System variables include appId, chatId, responseChatItemId, variables, and histories; chatId and responseChatItemId do not exist in test mode, so an empty value during debugging is not a business fault.
Return values are extracted by JSON path, and when the output type is set to string, the value of the corresponding key is converted into a json string. For the chat interface, passing body.appId in the request body is recommended, with Authorization used for authentication. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. Passed fields such as model and temperature have no effect; the orchestration decides them. With detail=true, responseData contains module status and complete results, and tokens require manual calculation. An interactive node returns an interactive object containing only type and params; internal runtime fields are not returned. Plugin calls default to detail mode, take inputs through variables, and expose outputs through pluginOutput.
Hypothetical drill sample: a negative-review handling record reads, "On 10 March 2025, Shop A received an order review in which the buyer reported that the goods did not match the description. Customer service has contacted the buyer to supplement evidence, and the purchase batch provided by Supplier B is PO-20250301, which the inventory ledger shows as received into stock." A draft sentence reads, "This negative review has been fully resolved, and Supplier B bears full responsibility." The pending request reads, "Synchronize the above handling result to the external customer-service system through the HTTP interface."
The record shows that customer service contacted the buyer to supplement evidence. It does not state that handling is complete, and it does not assign responsibility. The draft sentence is not supported by the record. The pending request is not an approval, and no synchronization has been executed.
Configuration and implementation checks
The table below lists settings or implementation checks that are documented in the official materials and relevant to this page's function and primary task. The starting values are hypothetical for this drill.
| Configuration item | Hypothetical drill starting point | Check note |
|---|---|---|
| Request URL | The interface address provided by the external customer-service system | The address can reference variables and must match the external interface documentation |
| Request method | POST | Choose according to the external interface documentation; Body takes effect only under the relevant request types |
| Headers authentication | Authorization: Bearer plus credential | Inject the credential through secure configuration; do not place it in a public sample |
| Body fields | Negative-review handling record, supplier batch, inventory status | Check the JSON structure against the external interface contract; string references need quotation marks |
| Return-value extraction | Extract the required field by JSON path | When the output type is string, the value is converted into a json string |
| Interactive node | detail=true returns interactive | It contains only type and params; continuing requires a further session request |
Three common errors
- Writing the draft sentence "This negative review has been fully resolved, and Supplier B bears full responsibility" into the request body as confirmed fact. The source record only shows that customer service contacted the buyer to supplement evidence. It does not record completion of handling or allocation of responsibility, so the draft sentence remains unsupported.
- Treating an empty chatId or responseChatItemId in test mode as a business fault. The documentation states that these two fields do not exist in test mode, so a debug environment and a production environment must be distinguished.
- Treating the interactive object returned by an interactive node as the complete runtime state and attempting to read entryNodeIds or nodeOutputs from it. The documentation states that these internal fields are not returned, and continuing requires a further session request in the specified format.
How to verify the setup
- Input the hypothetical source record and the draft sentence above. Compare whether "fully resolved" and "bears full responsibility" in the draft sentence have corresponding statements in the source record. The record only shows that customer service contacted the buyer to supplement evidence; it does not record completion of handling or allocation of responsibility. The draft sentence is unsupported.
- Input the pending request above. Compare whether the request body contains conclusive fields that the source record does not support. If the request body directly writes "fully resolved" or "Supplier B bears full responsibility," the content does not match the source evidence and must remain pending verification.
- Input batch PO-20250301 and the inventory ledger entry from the sample. Compare whether the batch number and the stock-received status in the request body match the source record. The record shows the batch as received into stock; if the request body writes another status, it does not match the source record.