What the documents look like
This page covers knowledge-base maintenance for order fulfilment and after-sales question handling. The working materials are FAQ entries, reply templates, product specification tables and escalation tickets. The activity is preparation of question-and-answer material ahead of live conversations; it does not approve refunds. Compared with platform refund and return processing, the work here is to collect frequent questions, rewrite standard replies and keep new product parameters current. Errors surface as answers that miss the question, escalated complaints or failed agent training. Source material is refreshed weekly or monthly, and that cadence governs version management of the knowledge content rather than the configuration of an HTTP integration.
Two features of this category shape the integration work. First, the material set spans structured parameter tables and free-text reply templates, so a request body assembled from variables may mix quoted strings with numeric and nested values. Second, escalation tickets carry a status that is distinct from any downstream business outcome, so a drafted reply can be checked against the source text without treating the ticket as an approval record.
Constraints at the HTTP integrations step
The HTTP module sends a request to a corresponding address. Params carry path request parameters and are used mostly with GET requests. Body carries the request body and is used mostly with POST and PUT requests. Headers carry special information. All three can reference variables through double curly braces, and the URL can also reference variables. Variables come from global variables, system variables and outputs of preceding nodes. The system variables are appId, chatId, responseChatItemId, variables, cTime and histories. The chatId and responseChatItemId values do not exist in test mode. Return values are extracted with JSON path syntax, and after output formatting the JSON value can be converted to a string for output.
The chat interface uses APIKey authentication. When calling chat/completions, the recommended practice is to pass body.appId in the request body; the form Authorization: Bearer <apiKey>-<appId> is also supported, and in that case body.appId is not required. The appId precedence order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. Some SDKs need a v1 path in BaseUrl and some do not; a 404 can be retried with v1 added. The model, temperature and similar parameter fields passed in do not take effect, because those are determined by the orchestration and do not change with API parameters. Proxying a team member identity through authProxy requires the team owner to enable authProxy when creating or editing the key, and the proxied identity still needs permission on the target application and conversation. That applies to FastGPT v4.15.0 and later.
When a workflow contains an interactive node, the interface returns immediately. With detail=true and stream=true, the interactive configuration is available from data.interactive under event=interactive. With stream=false, it appears in an element containing the interactive field inside choices[].message.content. The interactive value 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. Where an internal children, loop or tool wrapper interaction is hit, the interface returns the deepest user-facing interactive node. To continue the workflow, the same interface is called again with a consistent chatId; for a user-select interaction the chosen value is passed directly in messages, and for a form interaction the entered values are serialized into a string as the messages value.
A relevance score in retrieval results is a ranking basis for recall. It does not perform permission or entity isolation, and it does not exclude unrelated business records or unauthorized records. Retrieval is not authorization. Forms collect values; business verification, approval, database writes and external synchronization require their own downstream implementation.
Hypothetical paper exercise. A knowledge-base operator working on order fulfilment and after-sales question handling needs to check one drafted sentence. The source material reads: "Order A submitted a refund request on 10 March 2025, and the status is pending review. The customer-service system record shows that this request has not yet obtained approval." The drafted sentence reads: "The refund for Order A is complete, and the user can be told the refund has arrived." The check subject is Order A, the field is refund status, and the period is 10 March 2025. The source material records only pending review, while the drafted sentence asserts completion. These are mutually exclusive values for the same field on the same subject. The drafted sentence is not supported by the material and should be returned for revision; it must not enter the knowledge base as a standard reply.
Configuration and implementation checks
| Configuration item | Value or check in this exercise | Basis and explanation |
|---|---|---|
| Request address and method | Chosen according to the external interface document; the URL can reference variables | The document states that the URL can reference variables through double curly braces |
| Headers authentication | Authorization carries a Bearer credential injected through secure configuration | The document states that Headers carry special information |
| Body structure | Check the JSON fields against the external interface contract | The document states that Body takes effect only under specific request types |
| Variable references | Check each of global variables, system variables and preceding node outputs | The document states that all three variable sources can be referenced |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | An empty debug value is not treated as a business fault |
| Return value extraction | Configure the key using JSON path; the output type can be string | The document states that output formatting mainly converts JSON to string |
This exercise does not involve a database write or external synchronization. Those actions require a separately connected system implementation and are not listed in the configuration table.
Three common errors
- Treating a pending-review status as completed. The input is the source sentence "the status is pending review"; the comparison object is the drafted sentence "the refund is complete". Both address the same subject and the same field, and the values are mutually exclusive, so the drafted sentence is unsupported.
- Treating a retrieval relevance score as a permission filter. The input is the score field in a recall result; the comparison object is the business permission boundary. The score reflects textual relevance only and does not exclude unrelated business records or unauthorized records.
- Treating the display configuration returned by an interactive node as the complete runtime state. The input is type and params inside interactive; the comparison object is fields such as entryNodeIds and memoryEdges. The latter are not returned, so internal node state cannot be inferred from them.
How to verify the setup
- Against the source material and the drafted sentence, check whether the drafted sentence shares the same subject, field and period as the source. The input is Order A, refund status and 10 March 2025; compare the source value "pending review" with the drafted value "complete". Where the two values are mutually exclusive, the drafted sentence is unsupported and should be returned.
- Against a retrieval result, check whether the score field is being used for a permission judgement. The input is the score value in the recall list; the comparison object is the authorized business scope. Where the score is used only for ranking and does not participate in permission filtering, the behaviour matches the documented role of the similarity field.
- Against an interactive node response, check whether the returned content contains only type and params. The input is the interactive element inside choices[].message.content when stream=false; the comparison object is internal fields such as entryNodeIds. Where those internal fields do not appear, the response matches the documented description. All three checks are paper reviews; no actual request has been executed, and results depend on actual observation.