What the documents look like
On-demand retail fulfillment processes online orders minute by minute, so inventory procurement and supplier records must keep pace with each order rather than a periodic stock count. The main data sources are Douyin Instant Retail, the Meituan or JD Daojia back office, store inventory, and rider tracking. Daily documents include instant orders, picking lists, out-of-stock reports, and delivery exception forms. For inventory procurement and supplier records, the central requirement at this step is to connect purchase orders, goods-receipt records, supplier qualifications, and store inventory through HTTP integrations, so external systems can return results according to a contract.
The HTTP module sends a request to a given address. Params are path request parameters, Body is the request body, and Headers are request headers; all three can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables, and upstream node outputs. 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, and when the output type is string, the value of the corresponding key is converted into a JSON string. The chat API uses APIKey authentication, recommends passing body.appId in the request body, and also supports Authorization: Bearer <apiKey>-<appId>. Fields such as model and temperature have no effect because they are determined by the orchestration. Plugin calls default to detail mode, require no chatId or messages, pass input through variables, and return output through pluginOutput.
Constraints at the HTTP integrations step
A hypothetical paper exercise sample: a store handover record states, "Purchase order PO-2024-0517, supplier Xianda Trading, category leafy greens, arrival date 2024-05-17, quantity 120 units, status ordered, goods not yet received." A draft sentence awaiting judgment reads, "This purchase order has completed goods receipt and can be counted into current-period inventory." The record only states that the order was placed and does not record a goods-receipt action, so the draft sentence exceeds the source text.
The status field and the receipt action are separate facts. A record that only shows "ordered" does not support a statement that receipt is complete, and no authorization or effectiveness clause should be added to make the answer definite. The evidence gap remains a gap.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Request address and method | Address given by the external interface document, method POST | The address can reference variables and must be checked word by word against the interface contract |
| Headers authentication | Authorization: Bearer {{token}} | Credentials are injected through secure configuration and compared against the header field name |
| Body structure | Purchase-order fields declared according to the interface contract | Check whether the JSON structure matches the external contract |
| Variable reference | Reference the purchase order number from an upstream node output | Check each passed value against the source record |
| Return value extraction | Extract the status field through JSON path | Compare the extraction result with the interface response example |
| Output type | String output converted to JSON string | Compare with the format required by downstream text processing |
The values above are hypothetical starting points for this exercise, not official default values. No database write, approval, refund, or external synchronization is assumed at this step; those actions require their stated downstream implementation.
Three common errors
- Treating chatId and responseChatItemId, which do not exist in test mode, as a business failure. The check input is a test-mode request, the comparison is whether that field is referenced, and the observable result is whether a debug empty value is misreported as a business fault.
- Treating "ordered" in the record as "received." The check input is the sample source text, the comparison is the draft sentence against the source status field, and the observable result is whether the draft sentence exceeds the source scope.
- Treating retrieval or a form as authorized execution. The check input is a handover request, the comparison is whether the request states an authorization boundary, and the observable result is whether a pending review is treated as approved.
How to verify the setup
- Input the sample source text and the draft sentence. Compare whether "ordered" and "completed goods receipt" refer to the same subject and the same field. The draft sentence is not supported when the source only records the ordered status and no receipt action.
- Input a test-mode request. Compare whether chatId is referenced. A debug empty value is not a business fault when the field is absent by design in test mode.
- Input a handover request. Compare whether it states an authorization boundary and an effective status. A pending review is not an approval, and an offered option is not execution.
A relevance score is not a category, entity, or permission filter, and retrieval is not authorization. Where a document field is not provided, the field remains unknown. Missing evidence stays missing.