What the documents look like
Chain-store closure settlement handles exit and asset recovery, the opposite direction from headquarters site selection and store opening. Inventory procurement and supplier records draw on POS stock, the fixed-asset system, lease contracts and finance ledgers, and they update irregularly, once per store. Closure approvals, inventory clearance forms, lease termination agreements and asset count sheets form the main document set. The clearance form and the count sheet determine what a procurement return, supplier reconciliation or final payment request actually contains. These materials appear in concentrated form during the closure period, and an HTTP request has to reference upstream node outputs or global variables to pass store, supplier, clearance quantity and authorization status into an external system one item at a time.
Constraints at the HTTP integrations step
The HTTP module sends a request to the corresponding address, and its operation resembles direct-call tools such as Postman and ApiFox. Params carries path request parameters and is used mostly with GET requests. Body carries the request body and is used mostly with POST and PUT requests. Headers carries request headers for special information. A custom variable can receive the output of an upstream node as a variable, and all three data sections can reference variables through {{}}. The URL can also reference variables. Variables come from global variables, system variables and upstream node outputs. System variables include appId, chatId, responseChatItemId, variables, cTime and histories, where histories takes the most recent 10 entries by default and its length cannot be modified. Body takes effect only under specific request types. When a string is referenced inside Body, quotation marks are required, as in "{{string}}". Return values are extracted with JSON path syntax, and after v4.6.8 an output-formatting feature converts a value into a json string when the output type is set to string.
For the chat interface, APIKey authentication applies. 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 body.appId is then not required. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the legacy adaptation. Some SDKs need a v1 path in BaseUrl and some do not; if a 404 appears, adding v1 and retrying is permitted. Proxying a team member identity through authProxy requires the team owner to enable authProxy when creating or editing that key, and the proxied identity still needs permission for the target application and conversation; this applies only to FastGPT v4.15.0 and above. Passed-in fields such as model and temperature have no effect, because the orchestration decides them. Actual consumed Token values are not returned; if needed, detail=true can be set and the tokens value inside responseData calculated manually. chatId and responseChatItemId do not exist in test mode, so an empty value during debugging is an environment difference and not a business fault. When detail=true, intermediate values are returned and responseData holds module status and the complete result, which allows checking whether a request was actually sent and what came back.
Hypothetical drill sample: a store in the East China region of a chain brand submits an inventory clearance application during its closure period. The inventory clearance form reads: "Store number H-021, supplier number S-118, cleared goods are shelving and refrigeration cabinets, 42 items in total, clearance date is the third working day after closure approval, handler is store operations staff member Li, approval status is closure approval passed." The asset count sheet reads: "Same store and same supplier, counted quantity 42 items, count date is the day before the clearance date, counter signatures complete, no discrepancy noted." The draft handover request sentence to be judged is: "Based on the above two materials, initiate a 42-item return request to the supplier system and synchronously update the procurement ledger." The judgment points are: the subject is the same store and same supplier, the object is 42 items, the period is around the clearance date, and the field is quantity. The two materials agree on quantity, but the clearance form does not state return authorization terms, and the asset count sheet does not state supplier confirmation. The authorization boundary of this request is therefore unsupported, and supplier confirmation or contract terms must be added before execution.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting value for this page | Reason for the choice and comparison method |
|---|---|---|
| Request method | POST | Chosen per the external interface document; compare path-parameter usage against the GET example |
| Request address | Contains a {{baseUrl}} variable | The address can reference variables; compare maintainability against a fixed address form |
| Headers authentication | Authorization references a secure configuration | Credentials are not written into public samples; compare risk against a plaintext form |
| Body structure | References clearance form and count sheet fields | Takes effect only under the corresponding request type; compare against a request with missing fields |
| Return value extraction | key configured by JSON path | Output type string converts the value to a json string; compare against object output |
| detail value | true | Intermediate values are needed to check whether the request was sent; compare visible scope against false |
These values are hypothetical trial starting points for this page, not official default values. The comparison method is the difference in response for the same request under the two values.
Three common errors
- Treating an empty chatId in test mode as a business fault. Input is a request in test mode; the comparison item is whether chatId and responseChatItemId exist; the observable result is that the documents state they do not exist in test mode, which is an environment difference.
- Treating the clearance-form quantity as return authorization. Input is the two materials in the hypothetical sample; the comparison item is the quantity field against authorization terms; the observable result is that quantities agree while authorization is not stated, so the request is unsupported.
- Treating a
detail=falseresponse as proof the request was not sent. Input is the same request under twodetailvalues; the comparison item is whetherresponseDatacontains module status; the observable result is that intermediate values are absent when false, sotrueis needed for checking.
How to verify the setup
- Input the clearance form and count sheet text from the hypothetical sample, compare the store, supplier and quantity fields in the request body against the values actually passed, and the observable result is that fields correspond item by item and the quantity is 42, which satisfies the condition; if an empty value appears, record the gap.
- Input the draft handover request sentence, compare its authorization basis against the material text, and the observable result is that the text does not state return authorization, so the judgment is unsupported and supplier confirmation must be added.
- Input one address containing a {{baseUrl}} variable and one fixed address, compare the request results of the two forms, and the observable result is that the variable form can be substituted and the request is reachable; if a 404 is returned,
v1can be added and retried per the document. An empty result can be checked against the downstream design using the explicit paper input[]; no claim is made that a fictional rule must return[].