What the documents look like
Douyin storefront operations depend on product cards and store experience scores for traffic. The daily workload covers product qualification pages, experience score details, shipping violation appeals, and store announcements. In the procurement and supplier data task, purchase orders, supplier qualifications, arrival quantities, and shortage records sit across spreadsheets and external systems, with updates occurring daily and per order.
The HTTP module sends a request to a target address and behaves in practice like Postman or ApiFox. Params carry path request parameters and appear mostly in GET requests. Body carries the request body and appears mostly in POST and PUT requests. Headers carry request headers for special information. Custom variables can receive outputs from earlier nodes as variables. All three data locations, plus the URL, can reference variables through {{}}. Variables come from global variables, system variables, and earlier node outputs. Documented system variables include appId, chatId, responseChatItemId, variables, cTime, and histories, where histories defaults to a maximum of 10 entries and cannot be changed in length. In test mode, chatId and responseChatItemId do not exist, so an empty debug value is not a business fault.
The chat completions interface accepts an API key. 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 is not required. Some SDKs need v1 in the BaseUrl and some do not; a 404 can be retried with v1 added. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. When authProxy is used to proxy a team member identity, 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 model and temperature fields passed in are ineffective because the orchestration decides them. Actual consumed Token values are not returned; detail=true allows manual calculation from the tokens value in responseData.
Constraints at the HTTP integrations step
The return value configuration in the HTTP module represents how to parse the interface response, not the interface's own return value. Values are extracted through JSON path syntax. After FastGPT v4.6.8, output formatting mainly converts json into a string; when the output type is string, the value for the corresponding key is converted into a json string. This matters for procurement and supplier data because extracted supplier status, quotation, and arrival fields feed downstream text processing and AI dialogue nodes.
In the chat interface, when chatId is a non-empty string, the conversation is taken from the FastGPT database and only the last item in the messages array is used as the user question, with the remaining messages ignored. The chatId must be unique and shorter than 250 characters. When chatId is absent, no context is taken from FastGPT and the passed messages build the context entirely. responseChatItemId, when passed, becomes the response message ID and must be unique under the current chatId. Retrieval results and similarity scores do not carry authorization judgment; an interface call and a business approval are two separate matters.
Hypothetical paper exercise sample: the supplier data text to be checked reads "Supplier A, entity is XX Trading Co., Ltd., supplied category is disposable tableware, qualification page status is submitted and pending review, quotation valid until March 31, 2025." A handover request to be judged reads "add Supplier A to the qualified supplier list and generate a purchase order directly according to its quotation." The source text shows only that the qualification page is submitted and pending review. The quotation validity date belongs to the quotation field. The text does not state a supply period and does not state an approval result for the qualified list. In this request, "add to the qualified list" lacks approval evidence, and "generate a purchase order directly according to its quotation" treats the quotation validity date as authorization to execute procurement. Both are unsupported judgments.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point for this page | Check method |
|---|---|---|
| Request URL | External supplier data interface address, may contain {{}} variables | Compare character by character against the external interface document address |
| Request method | Chosen according to the external interface document | Compare against the method field in the document |
| Headers authentication | Authorization injected through secure configuration | Check the header key name; do not write credentials into public samples |
| Body structure | Used only under the corresponding request type; quoted variables for string references | Compare field by field against the external interface contract |
| Output key | Configured by JSON path, output type set to string | Compare against the parsed response structure |
| Variable source | Global variables, system variables, earlier node outputs | Check the actual passed values item by item |
Reason for the starting points: the request URL and method follow the external interface document, Body takes effect only under the corresponding request type, and the output key is configured by the JSON path syntax shown in the document examples. These starting points are compared against the corresponding fields in the external interface document and do not constitute official default values.
Three common errors
- Treating a qualification page status of "submitted and pending review" as approved. The input is the supplier data source text, the comparison is between the "pending review" and "approved" status values, and the observable result is that the two values differ and cannot substitute for each other.
- Treating the quotation validity date as a supply period or procurement authorization. The input is the quotation valid until March 31, 2025, the comparison is between the quotation field and the supply field, and the observable result is that the source text does not state a supply period, so that field remains unknown.
- Using a similarity score in place of a permission judgment. The input is the score value returned by retrieval, the comparison is between similarity and authorization status, and the observable result is that score does not indicate whether the supplier is approved, and retrieval does not produce authorization.
How to verify the setup
- Input the hypothetical sample source text and the handover request, compare "submitted and pending review" against "add to the qualified list" in the request, and observe that the request lacks approval evidence and is judged unsupported.
- Input the quotation validity field and the purchase order generation action, compare the quotation field against the authorization field, and observe that the source text states neither a supply period nor procurement authorization, so the judgment remains pending verification.
- Input the output key configuration and the parsed response structure, compare the key path against the response fields, and observe that extraction succeeds when the path and field match; when they do not match, that item remains unknown and is not inferred to be an interface fault.