What the documents look like
Omnichannel stock transfers move goods between stores and warehouses. The main data sources for this category are ERP inventory, store POS, e-commerce orders and WMS. The daily documents are transfer requests, inventory snapshots, store shortage lists and transfer logistics notes. Under the procurement and supplier records task, purchase orders, supplier profiles and receipt records must be aligned with those inventory movements. These documents update daily or weekly. This page does not cover batch synchronization or real-time trigger mechanisms.
A transfer request carries a status field, a supplier profile carries a contract signing date, and a receipt record carries arrival quantities. The HTTP integrations step connects these documents to external systems by sending requests and reading responses. The request construction and the return-value extraction are separate from any business approval, database write or external synchronization, each of which needs its own downstream implementation.
Constraints at the HTTP integrations step
The HTTP module sends an HTTP request to a given address. Params are path request parameters, used mostly with GET. Body is the request body, used mostly with POST and PUT. Headers carry special information. URL, Params, Headers and Body can all reference variables through {{}}. Variables come from global variables, system variables and preceding node outputs. The system variables include appId, chatId, responseChatItemId, variables, cTime and histories. The histories variable defaults to at most 10 entries and its length cannot be changed. chatId and responseChatItemId do not exist in test mode.
Return values are obtained by declaring keys that extract values from the interface response through JSON path syntax. When the output type is string, the value at the corresponding key is converted into a JSON string. The extraction rule follows JS object access rules; for example, the key data.user.name reaches a nested name, and data.list[1] reaches the second element of a list.
The chat completions interface uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended. For OpenAI SDK compatibility, Authorization: Bearer <apiKey>-<appId> is also supported, and then body.appId need not be passed. Some SDKs need v1 appended to BaseUrl and some do not; when a 404 occurs, adding v1 can be retried. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. To proxy team member identity through authProxy, the team owner must enable authProxy when creating or editing that key, and the proxied identity still needs permission on the target app and conversation. This applies to FastGPT >= v4.15.0. The passed model, temperature and similar parameter fields have no effect; these are determined by the orchestration. Actual consumed Token values are not returned; detail=true can be set and the tokens value inside responseData calculated manually.
Values collected by retrieval or by a form do not constitute business authorization. Database writes, approvals and external synchronization each need their stated downstream implementation. Retrieval is not authorization.
Hypothetical drill sample: a brand supply chain specialist holds a transfer request whose original text is dated 2025-03-10 and reads "Request to transfer 200 units of SKU-001 from warehouse A to store B, applicant: Li, status is pending approval." The specialist also holds a supplier profile whose original text reads "Supplier code SUP-018, contact: Wang, supplied category: SKU-001, contract signing date: 2025-01-05." The sentence to be judged is "This transfer request has been approved and can directly trigger a purchase order to SUP-018." The comparison scope is limited to these two materials.
Configuration and implementation checks
The following table is a hypothetical starting point for this drill, not an official default value. It is used only to explain the checking method.
| Configuration item | Hypothetical starting point for this drill | Reason for the choice and comparison object |
|---|---|---|
| Request address | Reference the address given in the external interface document | Compare character by character with the document address; do not assemble the path independently |
| Request method | Choose according to the external interface contract | Compare with the method declared in the document; do not choose by habit |
| Headers authentication | Inject credentials through security configuration | Compare with the authentication field required by the document; do not write plaintext credentials into the sample |
| Body structure | Build JSON according to the external interface contract | Compare field names and types item by item with the document |
| Variable reference | Reference preceding node output or global variables | Compare with the field names in the sample materials to confirm the value source |
| Return value extraction | Declare keys through JSON path | Compare with the structure of the response example to confirm the path level |
Three common errors
- Treating "pending approval" as already approved. The status field in the sample original text is "pending approval," while the sentence to be judged says "has been approved." The two take mutually exclusive values on the same field, which is a clear contradiction. The check input is the sample original text and the sentence to be judged; the comparison object is the status field; the observable result is whether the two values are consistent.
- Treating the contract signing date in the supplier profile as the supply period. The sample states only "contract signing date: 2025-01-05" and does not state a supply validity period. Direct ordering in the sentence to be judged lacks a supply period basis. The check input is the supplier profile original text; the comparison object is whether a supply period field is stated; the observable result is whether that field exists.
- Treating retrieval or form collection as authorized execution. In the sample the transfer request is in pending approval status, and ordering from SUP-018 requires the approval and procurement systems each to have their own downstream implementation. The check input is the request status and the proposed action; the comparison object is whether an approved record exists; the observable result is whether the authorization evidence is complete.
How to verify the setup
- Status field check. The input is the sample original text "status is pending approval" and the sentence to be judged "has been approved." Compare the values of the same status field. The observable result is that consistent values pass, while mutually exclusive values are judged a contradiction and require returning to the approval record for verification.
- Supply period field check. The input is the supplier profile original text. Compare whether that material states a supply period. The observable result is that a stated period is recorded, while an unstated period is recorded as an evidence gap without fabricating terms.
- Request construction check. The input is the request built according to the configuration table and the external interface document. Compare the address, method, Headers field names and Body structure. The observable result is that item-by-item consistency passes, while any inconsistency records the difference location without inferring the interface response.
A paper check of an empty result can use the explicit input [] to verify the downstream design; a fictional rule must not be claimed to return []. The same-model retrieval association requirement cannot be extended to require the same model for business registration sites or other external systems. A relevance score is not a category, entity or permission filter.