What the documents look like
E-commerce warehouse receiving performs the first physical-and-book confirmation when goods enter the warehouse. The main data sources are the WMS, ERP purchasing records, supplier delivery notes and barcode scanning. Daily documents include the purchase arrival note, the receiving inspection sheet, the put-away task and the discrepancy report. These materials update per batch and per day, and the HTTP integration step has to map requests from external systems against these documents item by item. Because receiving is the first reconciliation point, an incorrect field mapping here can produce stock that does not match the physical count, later picking errors and disputes with suppliers.
The HTTP module sends a request to a configured address with Params, Headers and Body, and the URL can also reference variables. Variables may come from global variables, system variables or the output of an upstream node, and {{}} references are permitted in all three data sections. 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 set to string, the value of the corresponding key is converted into a JSON string. The chat completion interface uses APIKey authentication, recommends passing body.appId in the request body when calling chat/completions, and also supports Authorization: Bearer <apiKey>-<appId>. Passed model, temperature and similar fields have no effect because the orchestration decides them. Retrieval and similarity scores do not carry authorization or entity-filtering duties.
Constraints at the HTTP integrations step
The HTTP module can be added repeatedly, is configured manually and is triggered to execute. Params are used mostly for GET requests, Body mostly for POST and PUT requests, and Headers carry special information. All three sections and the URL can reference variables drawn from global variables, system variables or upstream node output.
For the chat completion interface, the appId priority is body.appId, then <apiKey>-<appId>, then the appId associated with the API key under the older adaptation. Some SDKs need v1 added to the BaseUrl and some do not; if a 404 appears, adding v1 and retrying is the documented suggestion. When authProxy is used to proxy a team member identity, the team owner must have enabled authProxy when creating or editing the key, and the proxied identity still needs permission on the target application and conversation. This applies only to FastGPT versions at or above v4.15.0.
The interface does not return the actual consumed token value. To obtain it, set detail=true and calculate the tokens value in responseData manually. If a workflow contains an interactive node, the interface returns directly when the workflow reaches that node. With detail=true, stream=true the interactive configuration is obtained from data.interactive under event=interactive; with stream=false it is obtained from the element containing the interactive field inside choices[].message.content. The interactive returned to an external caller is a display configuration containing only type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs and nodeResponseId are not returned. When an internal children, loop or tool wrapper interaction is hit, the interface returns the deepest user-facing interactive node. To continue the workflow after an interactive node, the same interface is called again, and for form input the entered content is serialized into a string as the value of messages, with the object keys matching the form keys and the chatId kept consistent.
A hypothetical paper exercise sample: a warehouse receiving clerk processes a purchase arrival batch on 10 March 2026. The material text reads: "Purchase arrival note PO-2026-0310, supplier delivery quantity 120 pieces, WMS purchase order record arrival quantity 120 pieces, receiving inspection sheet records actual receipt 118 pieces, discrepancy of 2 pieces pending confirmation by the discrepancy report." A draft sentence awaiting judgment reads: "The arrival quantity of this batch matches the purchase order, and a put-away task can be generated directly." The request is in a pending-verification state and has not been authorized to execute put-away.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point for this page | Comparison method |
|---|---|---|
| Request address | The address given in the external interface document | Compare word by word against the interface document |
| Request method | Selected according to the external interface contract | Compare against the method field in the interface document |
| Params | Path parameters filled in per the interface document | Compare against the parameter table in the interface document |
| Headers | Authorization uses Bearer plus credential | Check the authentication method and credential source |
| Body | Used only under the corresponding request type, JSON structure checked | Compare against the fields in the interface contract |
| Variable reference | References a global variable, system variable or upstream node output | Check the actual passed value |
These values are hypothetical trial starting points for this page. The reason for choosing them is that the sample date and quantities already appear in the material text, and the comparison object is the corresponding field in that material text. They are not official default values of any kind.
Three common errors
- Treating "actual receipt 118 pieces" and "purchase order 120 pieces" in the material text as the same field, ignoring that a discrepancy of 2 pieces is pending confirmation by the discrepancy report, so the draft sentence "the arrival quantity matches the purchase order" lacks support.
- Treating the absent chatId and responseChatItemId values in test mode as a business fault, ignoring that the documentation states these do not exist in test mode.
- Treating a retrieval or similarity score as an authorization or entity-filtering mechanism, ignoring that retrieval does not carry authorization duties and that authorization requires a separate system implementation.
How to verify the setup
- Input the hypothetical sample material text above together with the draft sentence, compare the draft sentence "the arrival quantity matches the purchase order" against the source text "discrepancy of 2 pieces pending confirmation by the discrepancy report", and observe whether the same field shows mutually exclusive values. If the draft sentence does not cover the discrepancy field, judge it as unsupported.
- Input the purchase arrival note and the receiving inspection sheet from the hypothetical sample above, compare the quantity fields and the discrepancy field in both places, and observe whether the discrepancy of 2 pieces has been confirmed by the discrepancy report. While it is unconfirmed, record it as pending verification.
- Input the handover request from the hypothetical sample above, compare the request status against the authorization boundary, and observe whether a signature, approval or execution record appears. While the request is in a pending-verification state, record it as pending verification and do not judge it as authorized execution.
These are expected observations for the hypothetical sample and are not a claim that any test has been carried out. Where the material text does not state a field, the value remains unknown.