What the documents look like
Site selection and store opening work happens before a store begins trading, and it centres on lease negotiation and construction delivery. The working materials for this stage are the site assessment form, the letter of intent for the lease, the fit-out budget and the opening schedule. Procurement and supplier records travel in the same expansion document flow: supplier quotations, purchase lists and store schedules move alongside each other. The update rhythm is irregular and once per store. Headquarters expansion teams, regional development staff and engineering managers handle these records together, and mistakes carry consequences such as store losses, delayed handover or forfeited deposits.
The HTTP integration step takes fields from those materials, sends them to an external endpoint under that endpoint's contract, and retrieves a result that can be checked. It does not perform authorization, approval or database writes. Stock procurement and supplier data are the task focus here; the surrounding expansion documents supply the context in which requests are issued.
Constraints at the HTTP integrations step
The HTTP module sends a request to a chosen address. Params, Headers, Body and URL can each reference variables through {{}}. The available variables come from global variables, system variables and the outputs of preceding nodes. 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: the configured key determines which part of the response is read, and when the output type is set to string, the value at that key is converted into a JSON string.
The chat endpoint uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended, and an Authorization: Bearer form is also supported. The appId priority order is body.appId, then the apiKey and appId combination, then the appId associated with the apikey. Passed values for model, temperature and similar fields have no effect because the orchestration determines them. With detail set to true, intermediate values appear in responseData, and in stream mode they are distinguished by event. These are documented node behaviours and configurable fields. Business approval, database writes and external synchronization require separate downstream implementation.
Hypothetical paper exercise sample: a headquarters expansion team holds a paper record concerning a candidate store's supplier quotation. The record states that the status is "intent stage, quotation valid until 31 March 2026" and that the scope covers the opening schedule for the first quarter of 2026. The draft sentence to be assessed reads: "This supplier quotation has been submitted through the system interface and procurement receipt has been completed." The question is whether the material supports that sentence.
Configuration and implementation checks
| Configuration item | Value source | How to check |
|---|---|---|
| Request address BaseUrl | Given by the external interface document; this exercise starts from the address shown in that document | Compare character by character with the interface document |
| Request method | Chosen according to the external interface contract, for example POST | Compare with the method declared in the interface document |
| Headers authentication | Authorization injected through secure configuration | Confirm credentials are not written into public samples |
| Body structure | JSON declared according to the external interface contract, with referenced variables in {{}} | Compare field names with the interface contract |
| Return value extraction | Key configured with JSON path syntax | Compare with the interface response example |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | Confirm debug empty values are not treated as business faults |
The values in this table are starting points for this exercise, chosen so they can be compared against what the interface document declares. They are not official defaults.
Three common errors
- Writing a request address or method that does not match the external interface document. The check input is the address and method declared in the document; the comparison is between the configured BaseUrl and request method and that declaration; the observable result is that the two agree character by character.
- Omitting quotation marks when referencing a string variable in the Body, which changes the JSON structure. The check input is a Body declaration containing
"{{string}}"; the comparison is against the parsed result shown in the document example; the observable result is that the parsed types match the example. - Treating a retrieval result or a form submission as an authorization or an execution. The check input is the hypothetical sample wording "intent stage, quotation valid until 31 March 2026"; the comparison is against the draft sentence's claim of submission and completed procurement receipt; the observable result is that the material records neither submission nor receipt, so the sentence is unsupported.
How to verify the setup
- Using the hypothetical sample text, the input is "intent stage, quotation valid until 31 March 2026"; the comparison is against the draft sentence "submitted through the system interface and procurement receipt has been completed"; the expected observation is that the material records neither submission nor receipt, so the conclusion is unsupported and pending verification.
- The input is the Body declaration example given in the document; the comparison is against the final parsed example; the expected observation is that the parsed results for string, number, boolean, array and object match the example.
- The input is the interface response example together with the configured extraction keys; the comparison is against the extraction examples listed in the document; the expected observation is that each key returns the same value as the example. If the response is an empty array [], record an empty result and check the downstream design against it, without inferring that a rule must always return [].
This page addresses only one combination: chain-store site selection and store opening, stock procurement and supplier records, and HTTP integrations with external systems. Which materials, operations and requests sit at which authorization state during operational handover must be stated by the source material; a retrieval result or a form entry does not constitute an authorization.