What the documents look like
Wholesale market stall trading is fragmented. On-site price negotiation and shipping arrangements consume much of the working day, and the paperwork is scattered across paper and chat records: purchase slips, handwritten sales notes, stall lease contracts and payment receipts. Order fulfilment and after-sales question handling depend on moving the subject, object, status and validity scope recorded in those materials to an external system through an HTTP request, then checking what comes back. Because stall trading relies on on-site bargaining, documents frequently lack a unified serial number, which makes variable references and return-value extraction in the HTTP module the practical link in the verification chain.
A second characteristic matters here. Payment and delivery are often split into stages: a deposit collected through WeChat, a balance tied to a shipping document, and a delivery date agreed verbally. The HTTP step carries those staged facts outward, so the request body and the extracted response fields must be compared against the same stage, the same subject and the same field.
Constraints at the HTTP integrations step
The HTTP module sends a request to a specified address. Params, Headers and Body each support {{}} references to global variables, system variables and upstream node outputs, and the URL can also reference variables. System variables include appId, chatId, responseChatItemId, variables, cTime and histories; chatId and responseChatItemId do not exist in test mode. Return values are extracted through JSON path or JS object access rules, and when the output type is set to string, the value at the corresponding key is converted to a JSON string.
For chat interface calls, passing body.appId in the request body is recommended. Authentication also supports Authorization: Bearer <apiKey>-<appId>, and 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, non-streaming results are held in responseData, and tokens can be calculated manually.
Hypothetical paper exercise sample. A stall owner and a buyer agreed on a delivery date of 12 March 2025. The buyer has paid part of the goods payment through WeChat, and the balance is to be settled after the shipping document is signed for. Two sentences of source material are available: "Loading on 12 March; freight borne by the buyer." and "The balance is payable within three days after the shipping document is signed for." One draft sentence awaits judgment: "The buyer has settled the full goods payment, and the stall can arrange shipment." The comparison object is this draft sentence against the two source sentences. The source states only the condition for paying the balance and does not record that settlement has occurred, so the draft sentence is unsupported.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Request method | POST | Matches the external order interface document; compare the method actually marked in that document |
| Request address | The address given in the external interface document | The address can reference variables; compare the document address with the configured value |
| Headers | Authorization: Bearer {{token}} | The credential is injected through secure configuration; compare whether it leaks into a public sample |
| Body | JSON carrying the order object and the operation type | Effective only under the corresponding request type; compare the JSON structure with the interface contract |
| Return-value extraction | Extract the order status field by JSON path | Compare the extracted result with the corresponding field in the response text |
| Variable source | Upstream node outputs and global variables | Check each passed value; compare the configured reference with the node output |
Three common errors
- Treating an empty chatId or responseChatItemId in test mode as a business fault. Check: send a request in test mode, compare whether these two fields appear in the return, and observe whether an empty value is misjudged as a failure.
- Treating similarity or score as a permission or entity filter. Check: send a query unrelated to the stall order, compare whether the returned result still contains that record, and observe whether it is wrongly excluded or wrongly included.
- Treating a pending review or pending signature status as completed. Check: input the draft sentence "The buyer has settled the full goods payment," compare it with the source material, and observe whether the source records the settlement fact; when it does not, record the result as unsupported.
How to verify the setup
- Input the source sentences and the draft sentence from the hypothetical sample, and compare the draft sentence with the source. When the source does not record settlement, judge the draft as unsupported; do not judge it as contradictory or as a denial.
- Input an interface response containing an order status, extract the status field by the configured JSON path, and compare the extracted value with the corresponding field in the response text. When the two match, treat the extraction configuration as effective.
- Input a query that contains no order information, and observe whether the returned result includes unrelated records. When the return is empty or contains only clearly unrelated items, record the actual observation. An unrelated query returning empty is not assured.
The verification scope stays on the named primary task: comparing proposed copy sentences against the supplied source wording and its limits. Retrieval and relevance scores do not carry permission or entity isolation, and a same-model retrieval association requirement does not extend to business-registration sites or other external systems. No system error or automatic business action is asserted beyond what the supplied documents state. A pending request is not approval, an offered option is not execution, and an unsigned termination is not a completed termination.