What the documents look like
On-demand retail fulfillment processes online orders by the minute, which differs from the periodic stock-count rhythm of store inventory checks. The principal data sources are Douyin on-demand retail, the Meituan or JD Daojia back office, store inventory, and rider tracking. Data updates at minute level and per order. The daily documents are instant orders, picking lists, out-of-stock reports, and delivery exception tickets. For operating reports and exception reviews, fields from these documents travel through the HTTP module to external systems, or status is retrieved from external systems.
Two features of this category shape the integration step. First, each order produces its own document chain, so a report or review draws on many small records rather than one periodic batch. Second, status moves through several parties: the store, the platform back office, and the rider. An HTTP request can carry a document field outward or pull a status back, and the returned value is what the review compares against the store's own record.
Constraints at the HTTP integrations step
The HTTP module sends a request to the corresponding address. Params are path request parameters and are mostly used with GET requests. Body is the request body and is mostly used with POST and PUT requests. Headers are request headers and carry special information. All three locations can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables, and preceding node outputs. System variables include appId, chatId, responseChatItemId, variables, cTime, and histories. The chatId and responseChatItemId values do not exist in test mode. Return values are extracted through JSON path syntax, and when the output type is string, the value at the corresponding key is converted to a JSON string.
The chat interface uses APIKey authentication. Passing body.appId in the request body is recommended, and Authorization: Bearer <apiKey>-<appId> is also supported, in which case body.appId is not needed. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. The model, temperature, and similar parameter fields passed in have no effect, because those fields are determined by the orchestration. When detail=true, intermediate values are kept in responseData, and in stream mode they are distinguished through events. The interactive value returned for an interaction node contains only type and params; internal runtime fields are not returned. A relevance score is not a category, entity, or permission filter, and retrieval is not authorization.
Hypothetical drill sample. On 3 June 2025 at 14:20, a picking clerk at an on-demand supermarket store submits an out-of-stock report. The ticket number is QH-0603-014. The object is store A's ambient milk 250 ml. The status is submitted and awaiting duty supervisor review. The external system returns a status field with the value pending. The proposed handover sentence is: "This out-of-stock report has passed review and can be sent back to the platform."
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point for this drill | Reason for the choice and comparison method |
|---|---|---|
| Request address | The out-of-stock report query address given in the external system documentation | Compare word for word with the address given in the documentation |
| Request method | The GET or POST method marked in the documentation | Compare with the method marked in the documentation |
| Headers authentication | Authorization: Bearer {{token}} | Compare with the authentication description in the documentation; credentials are not written into public samples |
| Body fields | Ticket number QH-0603-014 and the store identifier | Compare with the field names in the external interface contract |
| Return value extraction | $.status | Compare with the field path in the response example |
| Output type | String | Compare with what the downstream text processing needs |
These values are the hypothetical trial starting points for this drill, not official default values. The request address may reference variables that have already been provided. The Body is used only under the corresponding request types, and its JSON structure is checked against the external interface contract. Authentication credentials are injected through secure configuration and are not written into public samples. The chatId and responseChatItemId values do not exist in test mode, so an empty value there is a debugging environment condition rather than a business fault.
Three common errors
- Treating a status value of pending as review passed. The input is the pending value returned in the sample. The comparison object is the status description "review passed." The observed result is that the two do not match, so the item is recorded as awaiting verification.
- Treating the absence of chatId and responseChatItemId in test mode as a business fault. The input is a request made in test mode. The comparison object is the documented absence of these fields in test mode. The observed result is an empty field, so the item is recorded as a debugging environment condition.
- Treating the display configuration returned for an interaction node as the complete runtime state. The input is an interactive value containing only type and params. The comparison object is the documented statement that internal fields are not returned. The observed result is the absence of fields such as entryNodeIds, so the item is recorded as display configuration.
How to verify the setup
- Input the sample source text "ticket number QH-0603-014, status submitted and awaiting duty supervisor review," together with the proposed handover sentence "this out-of-stock report has passed review." Compare the status field in the proposed sentence with the source text. The source text states only submitted and awaiting review, and does not state that review passed. When the proposed sentence does not match the source text, record it as unsupported and keep the evidence gap.
- Input the pending status value returned in the sample. Compare whether that value and the value for "review passed" are mutually exclusive values of the same field. When pending and review passed are not mutually exclusive values of the same field, record the item as awaiting verification rather than writing it as a negation.
- Input one hypothetical query request for this drill whose body contains ticket number QH-0603-014. Compare the extraction path
$.statuswith the actual field in the response. When the field is absent from the response, record it as missing and do not infer a system error cause. When the field is present, record the actual value.
These checks describe expected observations and do not claim that any test has been run. A pending request is not approval, and an offered option is not execution. The review compares the same subject, the same period, and the same field. Only mutually exclusive values of the same field count as a contradiction; a value that is not stated, or for which only evidence from a related stage exists, is recorded as unsupported or awaiting verification.