What the documents look like
The procurement and supplier records connected to retail checkout and loyalty work centre on four document families: promotional price tags, membership points rules, end-of-shift checkout reports, and exception refund slips. Price and membership entitlement are the operating thread; short-shelf-life stock does not enter this page. Data originates from the POS system, the membership CRM, the payment platform and the electronic shelf-label system, and the brief describes its update cadence as daily or per shift. That cadence shapes how the HTTP integration step is scoped: a request carries the specific values of one document, and the returned value is read back against that same document rather than treated as a standing synchronisation channel.
The integration step itself sends fields from those documents to an external service and parses the response. The HTTP module sends a request to a given address. Params carries path request parameters and is common in GET requests; Body carries the request body and is common in POST and PUT requests; Headers carries request headers. All three may reference variables with {{}}, and variables come from global variables, system variables, and outputs of preceding nodes. System variables include appId, chatId, responseChatItemId, variables, cTime and histories; histories takes at most 10 entries by default and its length cannot be modified. The URL may also reference variables. Returned values are extracted with JSON path syntax, and when the output type is set to string the value at the configured key is converted to a JSON string.
The chat interface uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended; appId priority runs body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. The model, temperature and similar fields passed in do not take effect, because the orchestration decides them. detail=true returns intermediate values, and in stream mode these are distinguished by event. When a workflow reaches an interaction node, the interactive value returned to the external caller is a display configuration containing only type and params; internal run-state fields such as entryNodeIds, memoryEdges, nodeOutputs and nodeResponseId are not returned, and if an internal children, loop or tool wrapper interaction is hit, the interface returns the deepest user-facing interaction node.
Constraints at the HTTP integrations step
Three features of this category carry directly into the integration work. First, price and membership entitlement are read from documents that carry their own approval state, so a request that submits a value to an external system has to be checked against the authorisation state recorded in the source document rather than against the existence of the field. Second, the same fields appear across the POS system, the membership CRM, the payment platform and the shelf-label system, so a returned value has to be compared against the specific document that supplied the input, not against a general expectation. Third, the update cadence described in the brief is daily or per shift, so a request is tied to one document version; nothing in the supplied material describes a batch, full, real-time or transaction-triggered synchronisation mechanism, and none is assumed here.
The module also carries a distinction that matters for verification. A configured key extracts a value from the response; it does not grant permission, and it does not filter records by business entity or authorisation. Retrieval and similarity are not authorisation. A form collects values; business verification, approval, database writes and external synchronisation require their own downstream implementation, which the supplied documents do not describe for this task. Where a request would need an approval step, a scheduled trigger or a hidden control, the material is silent and the gap stays open.
Hypothetical paper exercise. A store checkout supervisor, on the shift of 10 June 2025, needs to submit the item barcode and promotional price from a promotional price tag document to an external shelf-label system through an HTTP interface. The material supplied for checking reads: "Promotional price tag document number QJ-20250610-03; item barcode 6901234567890; promotional price 9.9 yuan; effective 10 June 2025 to 12 June 2025; approval status is pending review." The handover request to be judged reads: "Please submit this promotional price tag to the external shelf-label system through the HTTP interface and make it effective." The approval status is pending review, so the authorisation boundary for the submission action is not met. This is a paper exercise only; no submission, approval or effectiveness action is claimed to have occurred.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Request address and method | Address and method taken from the external shelf-label system interface document, referenced through {{}} | Compare character by character against the external interface document's path and method |
| Headers authentication | Authorization uses Bearer plus a credential injected through secure configuration | Compare against the authentication section of the interface document; the credential is not written into public samples |
| Body structure | Barcode and promotional price fields written according to the external interface contract | Compare item by item against the shelf-label system field description |
| Variable reference | Barcode and promotional price referenced from the output of a preceding node | Check that the value actually passed matches the promotional price tag document text |
| Returned value extraction | A key configured to extract the status field returned by the external system | Compare against the JSON path shown in the external interface response example |
| Debug identity fields | chatId and responseChatItemId are absent in test mode | Treat the empty debug values as absent, not as a business fault |
Three common errors
- Submitting a promotional price tag whose approval status is pending review directly to the external shelf-label system. The input is the material text "approval status is pending review"; the comparison object is the authorisation state the submission action requires; the observable result is whether the submission request is issued before that authorisation is satisfied.
- Referencing a string variable in Body without quotation marks, so the JSON does not parse as intended. The input is
{{string}}; the comparison object is the document's Body declaration, where referencing a string requires""; the observable result is whether the final parsed value is the expected string. - Treating intermediate values returned when detail=true as the final answer. The input is the module status inside responseData; the comparison object is message.content inside choices; the observable result is whether the field used downstream points at the final answer.
How to verify the setup
- Input the material text and the handover request from the hypothetical exercise above. Compare the approval status against the authorisation condition for the submission action. The condition is met only if no submission request is issued while the authorisation is unmet. No real submission is claimed.
- Input a Body declaration that contains a string variable. Compare it against the document's quoted form for string references. The condition is met when the final parsed value equals the expected string.
- Input a request with detail=true and stream=false. Compare the responseData field against the choices field. The condition is met when the final answer is taken from choices and the intermediate values are used only for checking.