What the documents look like
Cold-chain receiving produces records at batch level. A temperature log from the refrigerated vehicle, an arrival acceptance form, a rejection form and the supplier delivery note form one set tied to the same trip, the same store and the same arrival time. Temperature readings, sampling conclusions and rejection reasons are entered on separate forms, and the entry happens after measurement and sampling. These materials update per batch or per day, and the acceptance outcome directly affects supplier disputes and how the goods are handled. Before connecting such materials to an external system, confirm that the records themselves exist as complete entries, then discuss what the interface passes.
Two facts shape the HTTP integration step. The first is that the acceptance unit is a batch tied to a trip and a store, so any request body must carry identifiers that let the external service match the correct batch. The second is that several fields are produced only after physical work finishes, so a request drafted at handover time may reference values that do not exist yet. The arrival acceptance form and the rejection form carry different states, and the state of one does not establish the state of the other. Retrieval or a form collects values; business verification, approval, database writes and external synchronization each need their own downstream implementation.
Constraints at the HTTP integrations step
The HTTP module sends a request to a given address. Params carry path parameters, Body carries the request body, and Headers carry request headers. The URL can also reference variables through {{}}. Variables come from global variables, system variables and upstream node outputs. System variables include appId, chatId, responseChatItemId, variables, cTime and histories. In test mode, chatId and responseChatItemId do not exist. Return values are extracted with JSON path syntax, and when the output type is set to string, the value of the corresponding key is converted to a JSON string.
The chat interface uses APIKey authentication. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. Fields such as model and temperature passed in the request do not take effect, because the orchestration decides them. When a workflow contains an interactive node, the returned interactive object contains only type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs and nodeResponseId are not returned. A relevance score is not a category, entity or permission filter, and retrieval does not grant authorization.
Hypothetical drill sample. A store receiving system prepares a handover request to submit to an external acceptance service through the HTTP module. The source material reads: "On 10 March 2025, refrigerated trip C-0310 arrived at Store A; the temperature log shows an arrival temperature of 4.2 degrees Celsius; the arrival acceptance form registers sampled batch B-0310-02 with the conclusion pending quality-inspector review; no rejection form has been generated." The draft request sentence reads: "Submit this arrival acceptance conclusion to the external system and synchronize the rejection reason." The request contains a subject (Store A, trip C-0310), an object (batch B-0310-02), a state (pending review) and a validity scope (arrival on 10 March 2025). The rejection reason that the request asks to synchronize does not exist in the material, so that item is unsupported.
Configuration and implementation checks
The table below is tied to the sample above. The values in the middle column are starting points for this hypothetical drill only, used for comparison, and are not official defaults.
| Configuration item | Hypothetical drill starting point | Check method and reason |
|---|---|---|
| Request address and method | Fill in the URL and POST according to the external acceptance service document | The address can reference variables; the method must match the external interface contract |
| Params and Headers | Authorization injected through secure configuration | Check the source of the header value; credentials are not written into public samples |
| Body structure | Reference trip, batch and arrival time fields | Applies only under POST; check each JSON key against the external contract |
| Variable references | Reference batch and temperature from upstream node outputs | Confirm the variable comes from global variables, system variables or upstream node outputs |
| Return value extraction | Configure keys such as $.data.result | Extract by JSON path; choose the string output type as needed |
| Debug identity fields | Leave chatId and responseChatItemId empty | These two fields do not exist in test mode; an empty value is not a business fault |
Three common errors
- Writing the sample state "conclusion pending quality-inspector review" into the Body as a completed acceptance conclusion. The input is the draft handover request sentence, the comparison object is the state field in the source material, and the observable result is whether the request body carries a reviewed marker. The material registers only pending review and does not state that review finished, so that field is unsupported.
- Treating "synchronize the rejection reason" in the draft request as a submittable field. The input is the request sentence and the rejection form state, the comparison object is whether a rejection form has been generated and carries a reason, and the observable result is whether a rejection reason value exists in the Body. No rejection form has been generated, so the value is missing.
- Reading an empty chatId in test mode as a business fault. The input is the debug request and the system variable description, the comparison object is the condition under which chatId exists in test mode versus production mode, and the observable result is whether the error attribution lands on a missing identity field. The document states that this field does not exist in test mode.
How to verify the setup
- Input the source material text and the draft handover request sentence. Compare whether the acceptance conclusion field in the request Body matches "pending quality-inspector review." The observable result: if the request body writes a reviewed conclusion, it conflicts with the material state; if it keeps pending review, it matches the material. No test has been run.
- Input the draft handover request sentence and the rejection form state. Compare whether the request asks to submit a rejection reason. The observable result: the material has not generated a rejection form, so a request carrying that field lacks a source; record the gap without inferring that a rejection stands.
- Input the debug request. Compare whether chatId and responseChatItemId are empty. The observable result: in test mode these two fields do not exist, and an empty value is a documented condition rather than a business fault. Whether the external system accepts the request is a business action belonging to a separate system implementation, and this page makes no assertion about it.
An unsigned rejection is not a completed rejection, and a pending review is not an approval. Where the material does not state a value, the gap remains.