What the documents look like
After-sales repair and reship work aims to restore a product to use, and cases close through completed repair or a dispatched accessory reship rather than through a direct refund. This category draws on the after-sales system, the order system, repair outlets and the accessory warehouse WMS. The daily materials are repair applications, reship orders, inspection reports and accessory outbound orders. Updates arrive per order and per day, so report definitions need to align on both the document number and the date.
At the HTTP integrations step, the operating review task is to send fields from those documents to an external reporting service or ticketing system through HTTP requests. The FastGPT HTTP module can be added repeatedly, is configured manually and executes on trigger. It sends an HTTP request to the configured address. Params, Body and Headers each support {{}} variable references, and the URL also supports variable references. Variables come from global variables, system variables and upstream node outputs.
Constraints at the HTTP integrations step
System variables include appId, chatId, responseChatItemId, variables, cTime and histories. The chatId and responseChatItemId variables do not exist in test mode, so an empty value during debugging is an environment difference and does not by itself indicate a business fault. The histories variable takes at most 10 records by default, and that length cannot be changed.
The chat interface uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. To proxy a team member identity through authProxy, 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. Passed-in fields such as model and temperature have no effect because the orchestration decides them. With detail=true, intermediate values are returned, and in non-stream mode the result is stored in responseData.
Hypothetical drill sample. Source text for comparison: repair application WX-0715-03 states that the subject is a brand after-sales outlet, the object is a complete unit under order A, the fault description is that the power module does not start, the application date is 15 July, and the status is pending inspection. Accessory outbound order PJ-0716-11 states the same order, an accessory of one power module, an outbound date of 16 July, and a status of dispatched. The draft sentence to be judged is: this order has completed repair and been closed. Against those two documents, no inspection report is provided and no repair-completion or closure field is stated, so the draft sentence is unsupported.
Configuration and implementation checks
| Check item | Value or practice in this page's sample | Decision condition |
|---|---|---|
| Request address and method | Choose the address and method from the external interface documentation; the address may reference variables | Address matches the external interface contract |
| Headers authentication | Authorization is injected through secure configuration; the sample writes no plaintext credential | Credential does not appear in public sample text |
| Body structure | Used only under the corresponding request type, with JSON organized per the external interface contract | Field names match the external interface |
| Variable references | Reference upstream node outputs such as the repair application number, reship order number and outbound order number | Check each passed value item by item |
| Return value extraction | Configure a key with JSON path syntax; the output type may be string | Key matches the response structure |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | Empty values are recorded as an environment difference |
These practices come from configuration methods the public documentation describes, and no default numeric values are given. If this hypothetical trial sets a starting value of 20 for pageSize, the reason is to stay in the same order of magnitude as the value appearing in the conversation-list request example, and the comparison method is against the number of records the external interface accepts at one time.
Three common errors
- Treating a pending-inspection status as completed repair. In the sample, the repair application status is pending inspection and no inspection report is provided. If the report counts that order as completed repair, the input is the status field, the comparison object is the fields required for closure, and the observable result is an overcounted completion volume.
- Treating a dispatched accessory as a signed-for reship. In the sample, the outbound order status is dispatched and no receipt information is stated. If the report counts the outbound as signed for, the input is the outbound status, the comparison object is the receipt field, and the observable result is an overstated receipt rate.
- Treating an empty chatId in test mode as a lost conversation. In test mode chatId does not exist. If a conversation fault is declared on that basis, the input is the debug return, the comparison object is the production-call return, and the observable result is a rise in false reports.
How to verify the setup
- Input repair application WX-0715-03 and accessory outbound order PJ-0716-11 from the sample, and compare the draft sentence "this order has completed repair and been closed" against the fields stated in the two documents. When no inspection report and no closure field are stated, the sentence is judged unsupported, and the check passes when that condition is met.
- Input one chat/completions request carrying body.appId, and compare the module fields in the returned responseData against the model and temperature passed in the request. If the response does not change with the passed parameters, the parameters are decided by the orchestration, and the check passes when this matches the documented behavior.
- Input one request with detail=true and stream=false, and compare whether the response body contains both responseData and choices. Their simultaneous presence indicates that intermediate values and the final answer are both retrievable, and the check passes when this matches the documented behavior. If responseData is absent, record that no intermediate value was observed and keep the evidence gap.