What the documents look like
General trade import declaration work centres on the dutiable value, freight and insurance, and the payment of duties and taxes. Each declaration file brings together the import declaration form, the commercial invoice, the packing list, the bill of lading, and the contract. These materials are refreshed per declaration file. In the order fulfilment and after-sales question-answering stage, staff need external system status returned into the conversation flow so they can check the transaction terms, the freight and insurance entries, and the progress of customs inspection support. The HTTP module carries the fields that an external system returns into the dialogue; it does not perform declaration or duty payment actions.
Constraints at the HTTP integrations step
The HTTP module sends a request to a given address. Params are path request parameters and are used most often in GET requests. Body is the request body and is used most often in POST and PUT requests. Headers carry special information. All three can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables, and the outputs of preceding nodes. The return-value settings describe how to parse the interface response, using JSON path syntax to extract values. When the output type is set to string, the value at the corresponding key is converted into a JSON string. In test mode, chatId and responseChatItemId do not exist, so the absence of these two values during debugging is a mode difference rather than a business fault.
Hypothetical paper test sample: a commercial invoice states "Seller: A Trading Company; Buyer: B Import Company; Transaction terms: CIF; Invoice amount: USD 120,000; Contract number: HT-2024-018". A pending handover request reads "Please update the order status to cleared and notify the customer based on this invoice." The invoice text records only the seller and buyer, the transaction terms, the amount, and the contract number. It does not record the clearance status, and it does not record authorisation for the request to perform a status update or to send an external notice. The status update and the customer notification in this request are not supported and require separate verification of the clearance result and of the notification authorisation.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point for this page | How to check |
|---|---|---|
| Request address | The interface address supplied by the external system, which may reference a variable | Compare character by character against the external interface document |
| Request method | GET or POST selected according to the external interface document | Compare against the method marked in the document |
| Headers | Key is Authorization, value is Bearer plus the credential | Confirm the credential comes from secure configuration |
| Body | JSON written to the external interface contract, with strings quoted | Check fields and types against the contract |
| Return-value key | JSON path written according to the response structure | Verify the extracted result against the response example |
| Output type | When string, converted into a JSON string | Observe the output content against the expected structure |
The starting values come from the fields of this hypothetical paper sample and are not marked as default values in the documentation.
Three common errors
- Treating the absence of chatId and responseChatItemId in test mode as a business failure. The input is a test-mode request; the comparison is whether the response contains these two fields; the observable result is that the test-mode response does not contain these two values.
- Omitting the outer quotation marks when referencing a string variable in Body. The input is a Body declaration containing a string variable; the comparison is the final parsed result; the observable result is that the string is parsed as a JSON structure and fails.
- Treating the return-value key as the interface return value itself. The input is a response and a key; the comparison is the extracted result against the response text; the observable result is that the key only determines which part is extracted and does not change what the interface returns.
How to verify the setup
- Using the hypothetical sample invoice text and the handover request as input, compare "cleared" in the request against the transaction terms, amount, and contract number recorded in the invoice text. The invoice text does not record the clearance status. The observable result is that the status update is not supported and the clearance result requires separate verification.
- Using the hypothetical sample invoice text and the handover request as input, compare "notify the customer" against the seller and buyer recorded in the text. The text does not record notification authorisation. The observable result is that the notification request is not supported and the evidence gap remains.
- Using a Body declaration containing a string variable as input, compare the final parsed result against the original variable value. The observable result is that a quoted string parses as a string while an unquoted string fails to parse, which indicates whether the quotation marks are complete.