What the documents look like
Operating reviews and exception reviews for a Tmall flagship store draw on the Tmall merchant backend, Tmall rule center, ERP order tables, and customer service chat records. The daily documents in scope are product publishing pages, brand authorization letters, delivery commitment records, and after-sales tickets. Compared with JD POP stores, Tmall flagship stores place more weight on brand authorization, flagship store identity, and Tmall points compensation rules. That difference reaches the field definitions used by HTTP requests: one order may correspond to separate documents for authorization status, delivery commitment, and compensation record, so a request needs to state which document it is reading. Data updates daily and per order, and record-level checking treats a single record as the smallest unit.
Constraints at the HTTP integrations step
The HTTP module sends a request to a given address. Params carry path parameters and are used mostly with GET requests; Body carries the request body and is used mostly with POST and PUT requests; Headers carry request headers for special information. All three can reference variables through {{}}, and 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. The histories value takes up to 10 records by default and its length cannot be changed. Two of these fields behave differently in test mode: chatId and responseChatItemId do not exist under test mode. An empty value read during debugging is therefore an expected condition and does not indicate a business fault.
Return values are not the interface response itself. They describe how to parse the interface response, using JSON path syntax to extract values. After FastGPT v4.6.8, output formatting was added; when the output type is set to string, the value at the corresponding key is converted into a JSON string. This allows the HTTP output to feed a text processing node and then an AI chat node.
On the chat completions interface, the model and temperature fields passed in the request are not effective; these are determined by the orchestration and do not change with API parameters. Actual token consumption is not returned. To obtain it, set detail=true and calculate the tokens value inside responseData manually. Authentication uses an API key, and when calling chat/completions the recommended practice is to pass body.appId in the request body. For OpenAI SDK compatibility, Authorization: Bearer <apiKey>-<appId> is also supported, in which case body.appId is 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 the v1 path added to BaseUrl and some do not; if a 404 appears, adding v1 and retrying is the documented response.
Retrieval and forms collect and return values. Business authorization, approval, database writes, and external synchronization require separately implemented systems to carry them out. A relevance score is not a category, entity, or permission filter, and retrieval is not authorization.
Hypothetical paper exercise sample: a delivery commitment record awaiting verification reads, "Order number A1001, product is a flagship store main-line item, committed to ship within 48 hours, current status is shipped, logistics tracking number has been returned." A draft interface request awaiting judgment proposes to query the after-sales ticket for that order, writing {"orderId":"A1001","action":"get"} into the request body and referencing an Authorization variable in Headers. Whether this request has query scope for that order needs to be compared item by item against the authorization materials. The sample itself does not constitute an authorization conclusion.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason for the choice and comparison method |
|---|---|---|
| Request address | The order query address given in the external interface document | Compare character by character against the documented address; for variable references in the address, check the actual passed value |
| Request method | POST | Compare against the method marked in the interface document; when methods differ, the document governs |
| Headers authentication | Reference the Authorization variable | Check that the variable source is a secure configuration; do not write it into a public sample |
| Body structure | Contains the two keys orderId and action | Compare key by key against the interface contract; a missing key or mismatched type is recorded as a difference |
| Return value extraction | Configure the key using JSON path | Compare against the interface response example and observe whether the extracted result is the expected field |
| Output type | String | Compare against the type required by the downstream node; when types differ, adjust the extraction method |
Three common errors
- Treating an empty chatId or responseChatItemId under test mode as missing business data. Check: the input is a test-mode request; compare against the system variable description stating these do not exist under test mode, and observe whether the field is empty in the return. An empty value is a documented condition and does not constitute a business exception.
- Treating a similarity score or retrieval result returned by the interface as a permission decision. Check: the input is a query request containing only order number A1001; compare against the queryable scope for that order in the authorization materials, and observe whether returned records fall inside that scope. The similarity score is unrelated to permission, and out-of-scope records require separate verification of their authorization source.
- Treating values collected by a form as a completed business action. Check: the input is the draft request body
{"orderId":"A1001","action":"get"}; compare whether the request carries an authorization basis, and observe whether a database write or external synchronization occurs. When no authorization basis is carried, the request remains in a pending-verification state.
How to verify the setup
- The input is the delivery commitment record text and the draft request from the hypothetical sample. Compare the request body key names against the interface contract and observe whether orderId and action match the contract. When they match, the extracted result can proceed to the next check; when they do not, record the differing fields.
- The input is order number A1001 from the hypothetical sample. Compare against the queryable scope for that order in the authorization materials and observe whether all returned records fall inside the scope. Records outside the scope remain pending verification and are not used to declare the query successful or failed.
- The input is a request with detail=true and stream=false. Compare the module entries in the returned responseData structure and observe whether the required node response is present. When it is absent, record the gap and do not infer a specific error cause.