What the documents look like
Marketplace refund and return handling occurs continuously per order and does not necessarily connect to a single livestream commitment. The working materials are refund applications, return logistics waybills, quality-inspection photos, and refund approvals. They arrive from the platform after-sales console, customer-service chat, WMS receiving records, and payment refund records. Updates occur per order and daily.
This page addresses one step inside order fulfillment and after-sales question answering: the HTTP integration and external-system layer. That step covers the request address and method, Params and Headers, Body, variable references, and the identity fields used during debugging. These values live in several systems at once, so each reference must be traced to a global variable, a system variable, or an upstream node output before it is sent. A retrieval result or a form entry collected in a conversation is not the same thing as an authorization to act.
Constraints at the HTTP integrations step
The HTTP module can be added repeatedly, configured manually, and triggered to execute. Params carry path request parameters and appear mostly in GET requests. Body carries the request payload and appears mostly in POST and PUT requests. Headers carry request headers. All three data locations can reference variables through {{}}, and the URL can also reference variables. System variables include appId, chatId, responseChatItemId, variables, cTime, and histories. In test mode, chatId and responseChatItemId do not exist, so an empty debug value is a known test condition rather than a business fault.
Return values are extracted through JSON path. When the output type is set to string, the value at the corresponding key is converted into a JSON string. The chat completion interface uses APIKey authentication, and appId priority runs as body.appId, then the apiKey-appId combination, then the appId associated with the apikey. The model, temperature, and similar parameters passed in the request body have no effect because the orchestration determines them. Proxying a team member identity through authProxy requires the team owner to enable it when creating or editing the key, and the proxied identity still needs permission on the target application and conversation. An interactive node returns an interactive object containing only type and params; internal runtime fields are not returned. Form input must be serialized into a string and passed as the messages value, and chatId must stay consistent across the continuation request. These conditions mean each call has to be checked item by item, and a value collected by a form cannot be assumed to equal completed business verification or authorization.
Configuration and implementation checks
Hypothetical paper exercise: on 10 June 2025 an after-sales specialist processes the refund application for order A-0610. The supplied material reads: "Refund application RF-0610, order A-0610, the consumer claims the goods arrived damaged, two quality-inspection photos uploaded, return waybill SF-0610 shows signed for, refund approval status pending review." The draft sentence under review reads: "Return liability for this order is confirmed; the refund can be executed." This sample is used only to check HTTP request variable references and external-system return parsing. It does not represent any real business action.
| Configuration item | Hypothetical starting point for this exercise | Check description |
|---|---|---|
| Request address and method | Chosen from the external interface contract | The address can reference a variable; the method must match the external contract |
| Params and Headers | Keys and values checked item by item | Authentication credentials are injected through secure configuration and kept out of public samples |
| Body | Used only under the applicable request type | JSON structure checked against the external interface contract |
| Variable reference | Global variables, system variables, or upstream node outputs | Each actual passed value is checked; a retrieval result is not treated as authorization |
| 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 | Extracted through JSON path | When the output type is string, the value is converted into a JSON string |
Three common errors
- Treating a refund application value collected by a form as completed authorization. Input: the sample material and the draft sentence. Comparison point: the refund approval status field. Observable result: the status reads pending review, which does not constitute approval, so the draft sentence is unsupported.
- Treating the absence of chatId in test mode as an interface failure. Input: a test-mode request. Comparison point: the documented test-mode condition. Observable result: the field is documented as not existing in test mode, which is a known debug condition.
- Treating a value extracted through JSON path as a business verification result. Input: the return value extraction configuration. Comparison point: the materials the sample requires for a liability judgment. Observable result: the extracted value represents parsing of the interface response, and liability still requires manual checking of the quality-inspection photos and the return waybill.
How to verify the setup
- Against the draft sentence "Return liability for this order is confirmed; the refund can be executed," input the refund approval status "pending review." Compare whether that field states approval. The draft sentence is unsupported when approval is not stated, and the evidence gap is recorded.
- Against the sample line that return waybill SF-0610 shows signed for, input the HTTP return value extraction configuration. Compare the extracted signed-for field with the manual verification scope. The signed-for record supports the fact of logistics arrival only and does not constitute a refund liability determination.
- Against a test-mode request, input chatId and responseChatItemId. Compare them with the documented test-mode absence condition. When both are empty, this is a known debug condition and is not used to judge a business fault.
All three checks are paper comparisons. They do not indicate that any test was run or that any business action was executed.