What the documents look like
Complaints and official replies in this category revolve around four document families: complaint tickets, regulatory inquiry letters, order evidence, and rectification reports. The work faces a platform or a regulatory authority, so the material needs formal evidence and formal corrective wording rather than conversational reassurance. Data arrives from the 12315 platform, platform complaint centers, customer service chat, and the order system. Updates are irregular and case by case.
For the operating review and exception review task on this page, the HTTP module is the connection point. Ticket status, reply progress, and evidence package submission are sent out through the HTTP module to an external system, or results are pulled back, so that reviewers can look at exceptions across cases. Fields not described in the supplied documents remain unknown. This page does not assume that a regulatory portal, a platform complaint center, or an order system exposes any particular endpoint, field, or schedule.
A working assumption for this page is a paper exercise only. The material under review is a complaint ticket record with the text: "Complaint ticket number TS-2024-0312, subject is one store, object is the order dated 5 March 2024, status is regulatory inquiry reply submitted, reply date 12 March 2024." The draft sentence to be judged is: "This ticket has completed rectification and been closed." The draft does not match the source. The source records only that a reply was submitted. It does not record that rectification was completed or that the case was closed, so the draft sentence is unsupported.
Constraints at the HTTP integrations step
The HTTP module sends an HTTP request to the configured address. Its practical behavior is close to tools such as Postman and ApiFox. Params are path request parameters and are mostly used with GET requests. Body is the request body and is mostly used with POST and PUT requests. Headers carry request headers for special information. Custom variables can receive output from earlier nodes. Params, Body, Headers, and the URL can all reference variables with {{}}. Variables come from global variables, system variables, and earlier node output.
The documented system variables are appId, chatId, responseChatItemId, variables, cTime, and histories. Histories takes at most 10 entries by default, and that length cannot be changed. chatId and responseChatItemId do not exist in test mode. A test-mode request therefore carries no value for these fields, and an empty value there is a property of the mode, not evidence of a business fault.
Return values are configured as extraction rules, not as the raw interface response. The module extracts values from the interface response using JSON path syntax, and the configured key follows JavaScript object access rules. From the documented response example, message retrieves the top-level message, data.user.name retrieves the nested user name, and data.list[1] retrieves the second list element. Since FastGPT v4.6.8, output formatting mainly converts JSON to a string. When the output type is set to string, the value at the corresponding key is converted to a JSON string.
For the chat completions interface, the documented key guidance is to pass body.appId in the request body. 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; if a 404 occurs, adding v1 and retrying is the documented step. The documented appId priority is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. The model and temperature fields passed in are ineffective; the orchestration determines these and they do not change with API parameters. Actual token consumption is not returned. Setting detail=true returns responseData, and tokens inside responseData can be calculated manually. Using authProxy to proxy a team member identity 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. These are documented conditions, not automatic grants.
Configuration and implementation checks
The table below is tied to the paper exercise above. Each row lists a documented setting or an implementation check, and the starting value is a hypothetical starting point for this exercise, not an official default. Where a value is not documented, the row states the comparison method instead of inventing a number.
| Configuration item | Starting point for this exercise | Reason and comparison object |
|---|---|---|
| Request address and method | Fill per the external interface document | Compare against the external interface contract and check that path and method match |
| Headers authentication | Authorization with Bearer and variable injection | Compare against the key usage guidance; do not write credentials into public samples |
| Body structure | JSON built per request type | Compare field by field against the external interface contract |
| Variable references | appId, chatId and other system variables | Compare against the actual output of earlier nodes |
| Return value extraction | Configured key and JSON path | Compare against the documented response example |
| detail value | Hypothetical starting value true | Choose true when intermediate values are needed; compare against the false response structure |
Three common errors
- Treating a debug identity field as a business fault. Input is a test-mode request. Compare the actually passed values against the system variable description, which states that chatId and responseChatItemId do not exist in test mode. The observable result to watch for is a judgment that an empty value is a fault, when the empty value is expected in that mode.
- Treating retrieval or a form as authorization or execution. Input is a request that reaches an interactive node. Compare the returned interactive display configuration, which contains only type and params, against the authorization state of the case. The observable result to watch for is treating a collected form value as an approved action or a completed business step.
- Treating an unstated status as a negative conclusion. Input is the sample source text and the draft sentence. Compare the source status "regulatory inquiry reply submitted" against the draft claim "completed rectification and been closed." The observable result to watch for is a definite conclusion that the source does not support. The source records a submitted reply only; rectification completion and closure are not recorded.
How to verify the setup
- Input the sample source text and the draft sentence. Compare the source status field against the assertion in the draft. The draft sentence is supported only when the source explicitly records both rectification completion and closure. In this exercise the observed result is unsupported, and the missing record remains missing.
- Input a request with
detail=true. Compare the tokens field insideresponseDataagainst a manually calculated value. The observable result is whether the tokens can be accounted for from that field. This page does not claim the calculation was performed or that any request was actually sent. - Input a paper response of an empty array
[]. Compare how the downstream node is designed to receive an empty array. The observable result is whether any statement claims that a retrieval rule returns[]by design. No such rule is documented, so the empty-array handling remains a design question for the downstream node, and the missing evidence stays missing.
The verification above tests the named primary task of this page: drafting and reviewing reply text for complaint and regulatory cases against the supplied source wording and its limits. A relevance score is not a category, entity, or permission filter, and retrieval is not authorization. A pending request is not approval, an offered option is not execution, and an unsigned termination is not a completed termination. Where the documents do not state a field, value, schedule, or downstream action, this page records the gap rather than filling it.