What the documents look like
Export tax rebate filing happens after goods leave the country, and the work centers on matching tax vouchers. The main data sources are the electronic tax bureau, the export tax rebate filing system, customs electronic information, and the financial ledger. The documents handled day to day are the export tax exemption and rebate filing form, the export customs declaration, purchase invoices, and foreign exchange receipt vouchers. Data updates by month or by batch. Matching invoices against customs declarations, generating filing data, and handling discrepancy feedback are the time-consuming steps. Operating reports and exception reviews are built around these documents, and the HTTP integration step sends requests to external systems and extracts returned values.
For this task, the documents carry quantities and statuses that a review draft must reproduce exactly. A filing form states how many customs declarations belong to a batch. A purchase invoice carries an invoice number that either matches a declaration in the filing system or does not. A foreign exchange receipt voucher carries a collection status. These are the values an operating report or exception review compares, and the HTTP step moves them between systems without changing what they mean.
Constraints at the HTTP integrations step
The HTTP module sends an HTTP request to the corresponding address, and its operation is close to tools such as Postman and ApiFox. Params are path request parameters, used mostly in GET requests. Body is the request body, used mostly in POST and PUT requests. Headers carry special information. Custom variables can receive the output of earlier nodes as variables. All three data sections can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables, and earlier node output.
System variables include appId, chatId, responseChatItemId, variables, cTime, and histories, where histories by default takes at most 10 records and the length cannot be modified. chatId and responseChatItemId do not exist in test mode. In Body, a referenced string needs quotation marks, while numbers and booleans are referenced directly. Return values are configured to describe how to parse the interface response, using JSON path syntax to extract values. When the output type is string, the value at the corresponding key is converted to a JSON string.
Authorization follows the chat interface rules. Calling chat/completions uses APIKey authentication, and passing body.appId in the request body is recommended. For OpenAI SDK compatibility, Authorization: Bearer <apiKey>-<appId> is also supported, in which case body.appId is not passed. Some SDKs need v1 added to BaseUrl and some do not; if a 404 appears, adding v1 can be retried. The appId priority is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. 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 application and conversation. The passed model, temperature, and similar parameter fields have no effect; these are determined by the orchestration.
Hypothetical drill sample: a foreign trade enterprise finance staff member prepares exception review material for a March 2025 export tax rebate filing batch. The material reads: "This batch has 12 export customs declarations in total, of which the purchase invoice numbers of 3 declarations did not match successfully in the filing system; 9 foreign exchange receipt vouchers have been collected, and the remaining 3 are in pending collection status." The draft sentence to be judged is: "All customs declarations in this batch have completed invoice matching and can be submitted for filing." The draft sentence and the source material need item-by-item comparison on matching quantity and collection status.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this drill | Reason for the choice and comparison method |
|---|---|---|
| Request address | The address given in the external interface document | The address can reference variables; compare character by character with the documented address |
| Request method | The method specified by the document | Compare with the external interface contract to confirm the method agrees |
| Params | The path parameters listed in the document | Check each key and value, confirming none is missing |
| Headers | Authorization uses Bearer plus credential | The credential is injected through secure configuration and not written into public samples |
| Body | Filled according to the documented JSON structure | Check field types; strings take quotation marks, numbers are referenced directly |
| Return value extraction | Keys configured by JSON path | Compare with the interface response example to confirm the extraction path exists |
These are implementation checks tied to this page, not documented defaults. The starting values describe what a reviewer would compare against, and the comparison method states what the value is checked against.
Three common errors
- Treating the return value configuration as the interface return value itself. The return value configuration describes how to parse the interface response and needs extraction by JSON path. Check: input an interface response example, compare the configured key with the actual path in the response, and observe whether the extracted result agrees with the corresponding field in the response.
- Treating empty chatId and responseChatItemId in test mode as a business fault. The documentation states these two fields do not exist in test mode. Check: input a test-mode request, compare the returned result with the formal-mode difference, and observe whether only these two fields are absent.
- Treating retrieval or form filling as authorized execution. Forms collect values, and business verification, approval, and database writes need downstream implementation. Check: input a handover request awaiting review, compare the request status with the approval record, and observe whether evidence of a completed approval exists.
How to verify the setup
- Input the source material and draft sentence from the hypothetical sample, compare the draft sentence "all customs declarations have completed invoice matching" with the source "3 did not match successfully," and observe whether the draft sentence agrees with the source quantity. If it does not agree, the draft sentence is unsupported.
- Input the foreign exchange receipt voucher status from the hypothetical sample, compare "9 collected" with "3 pending collection," and observe whether the draft sentence omits the pending collection status. If it omits it, a note to be verified needs to be added.
- Input an HTTP request configuration, compare Params, Headers, and Body with the external interface document, and observe whether the return value extraction path exists in the response example. If the path does not exist, the extracted result is empty, and the document needs to be checked before adjustment.
A pending review does not show that operating permission is absent. A retrieval result does not grant authorization, and a relevance score is not a category, entity, or permission filter. Where the source material states a quantity or status, the draft is judged against that same subject, period, and field. Where the material does not state a value, the item remains unsupported or pending verification, and the evidence gap stays open.