Channel diversion reviews: HTTP integrations for after-sales questions

Review HTTP integrations for after-sales questions in Channel diversion reviews. Check input mappings, source evidence and failure handling before use.

What the documents look like

Channel diversion reviews address regional and price order. They do not address rebate amounts. The working materials are diversion complaint forms, anti-counterfeit code records, penalty notices and investigation photographs. In order fulfilment and after-sales answering, these materials reach an HTTP integration as a complaint number, an anti-counterfeit code, a shop link, shipment record fields and photograph links. The brief states weekly and irregular update frequency, so calls in this step are usually triggered by staff handling a complaint or answering a distributor. No scheduled trigger is documented.

Constraints at the HTTP integrations step

The HTTP module sends a request to a given address. Params, Body, Headers and the URL can reference variables through {{}}. Variables come from global variables, system variables and preceding node outputs. The documented system variables are appId, chatId, responseChatItemId, variables, cTime and histories. The documents state that chatId and responseChatItemId do not exist in test mode, so an empty value seen while debugging is not a business fault. When calling chat/completions, appId priority is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. The model and temperature fields passed in the request have no effect because the orchestration decides them. With detail=true, the tokens inside responseData can be used for manual calculation. The authProxy option requires the team owner to enable it when creating or editing the key, and the proxied identity still needs permission on the target app and conversation. An HTTP request by itself does not confirm a diversion fact, a penalty authority or a refund eligibility. Retrieval and form collection do not create authorization.

Hypothetical paper exercise: a diversion complaint form reads "complaint number XC-2024-0312, complained shop is platform shop A, complaint product anti-counterfeit code 8801 was scanned on 5 March 2024 outside the East China region, two investigation photographs attached, distributor shipment records show the code batch was sent to South China." A draft sentence under review reads "the diversion fact of this shop is established, and a deduction is agreed under the penalty notice." In this exercise the complaint form records only the scan location and the batch flow. It does not state a penalty approval opinion. The draft sentence turns a fact still to be verified into an established fact and moves directly to executing a deduction, which exceeds what the material supports.

Configuration and implementation checks

Configuration itemHypothetical trial starting pointReason and comparison method
Request addressThe query address written in the external anti-counterfeit system documentCompare character by character with the path given in the external interface document
Request methodGET for queries, POST for submissionsCompare with the method declared in the external interface contract
ParamsFill in the anti-counterfeit code field reference {{code}}Compare with the anti-counterfeit code value in the complaint form text
HeadersAuthorization uses Bearer with a credential variableCheck that the credential comes from secure configuration; it is not written into the exercise
BodyBuild JSON per the external contract when using POSTCompare field names and types item by item with the external interface document
Return value extractionConfigure the key by JSON pathCompare with the actual response structure and confirm the target value is obtained

These starting points are values for this hypothetical trial. They are not official defaults. The documents give no default for numeric settings, so none is specified here.

Three common errors

  1. Treating an empty chatId or responseChatItemId in test mode as an interface fault. Check: confirm whether the current mode is test mode, compare against the documented condition that these fields do not exist in test mode, and observe whether the field is empty only in the test state.
  2. Treating a scan-location record in a complaint form as an established diversion fact. Check: compare the draft sentence with the complaint form text sentence by sentence. When the text states no penalty approval opinion, mark the sentence as unsupported.
  3. Treating an HTTP query result as authorization to execute a penalty. Check: verify whether the returned content is only a data query result, compare with the approval status field of the penalty notice, and confirm that execution cannot proceed when no approval record exists.

How to verify the setup

  1. Input the complaint form text and the draft sentence from the hypothetical exercise. Compare whether the draft sentence introduces "fact established" and "execute deduction" that the text does not state. Observe whether the draft sentence is marked as pending verification when the text has no approval opinion.
  2. Input the anti-counterfeit code field reference {{code}}. Compare the value actually passed with anti-counterfeit code 8801 in the complaint form text. Observe whether the extracted result matches the text.
  3. Input a request with detail=true. Compare whether a tokens field appears in responseData. Observe whether manual calculation is possible from it. If the return is an empty array, check the downstream design against the paper input rather than inferring that a fictional rule must return empty.

These are paper checks only. No interface was actually called, and no approval, deduction or synchronization action occurred.