What the documents look like
Picking, checking and packing handle outbound orders rather than supplier arrivals, so the working materials are wave picking lists, checking records, shipping labels and packaging consumable sheets. These records update per order or per hour, and a single wrong or missing shipment moves directly into after-sales compensation. In the HTTP integration step, those materials mainly appear as request parameters, request body fields or return-value extraction targets. The interface itself does not change the picking, checking or packing conclusion.
A wave picking list carries a wave number, an order number, item quantities, a picking scan state and a checking state. A checking record carries the order number, the checker's confirmation of quantity and a checking result with a timestamp. A shipping label and a packaging consumable sheet carry their own identifiers and quantities. None of these documents by itself states that packing is complete, and none of them grants an external system the authority to act on the order.
Constraints at the HTTP integrations step
The HTTP module sends a request to a specified address. Params are mostly used for GET requests, Body is mostly used for POST and PUT requests, Headers carry special information, and all three data types plus the URL can reference variables through {{}}. Those variables come from global variables, system variables and upstream node outputs. Return values are extracted with JSON path syntax, and output formatting mainly converts JSON into a string.
The chat completions interface uses APIKey authentication. A recommended form passes body.appId in the request body, and a compatible form uses Authorization: Bearer <apiKey>-<appId>. The model and temperature fields passed in are invalid because the orchestration decides them. An empty chatId means no context is used and the full messages array builds the context; a non-empty chatId means the database conversation is used and the last message becomes the user question. responseChatItemId must be unique under the current chatId. Intermediate values are returned only when detail=true. In test mode, chatId and responseChatItemId do not exist.
Hypothetical paper exercise: the wave picking list supplied for checking reads "Wave W-0715, order O-2231, item A two units, picker has scanned, status is pending check." The checking record reads "O-2231, checker has verified quantity, status: check passed, time 2025-07-15." The draft handover request under judgment reads "Based on the two records above, send an HTTP request to the external order system stating that O-2231 has completed packing." Neither source text states that packing is complete, and neither source text states that the external system is authorized.
Configuration and implementation checks
The table below is a hypothetical starting point for this exercise, not an official default.
| Configuration item | Starting point in this exercise | Reason and comparison object |
|---|---|---|
| Request address | External order system endpoint, referenced through a variable | Compared with the address given in the external interface document |
| Request method | POST | Compared with the method declared in the external interface document |
| Headers | Authorization references a credential variable | Compared with the field required by the authentication specification |
| Body fields | Reference the wave number and order number variables | Compared item by item with the external interface contract fields |
| Return-value extraction key | JSON path configured against the response structure | Compared with the response example structure |
| detail | Set to true when intermediate values are needed | Compared with whether responseData is required |
Three common errors
- Treating a picking list status of "pending check" as a passed check and sending a packing-complete request on that basis. Check: input the two source texts, compare the status fields against the request content, and confirm that the send condition is met only when the checking record shows a passed check and evidence of completed packing exists.
- Treating an empty
responseChatItemIdin test mode as a business fault. Check: input the test-mode request, compare the returned value against the documented statement, and confirm that the field not existing in test mode is expected. - Writing the return-value extraction key as the raw field name from the external interface and ignoring the FastGPT converted format. Check: input the interface response example, compare the configured key against the converted structure, and confirm that the condition is met only when the field path matches.
How to verify the setup
- For the hypothetical exercise, input the wave picking list and checking record source texts, compare the Body fields of the intended request against both source texts, and confirm that the condition is met only when every field value has corresponding evidence in the source texts. The packing-complete statement in the draft request has no supporting evidence in either source text, and the authorization status of the external system remains unknown.
- For the authentication configuration, input the Headers configuration, compare the Authorization value form against the two documented forms, and confirm that the condition is met when either documented form is followed.
- For return-value extraction, input the interface response example, compare the configured key against the JSON path extraction result, and confirm that the condition is met only when the extracted value matches the example.
All three steps are paper checks. No interface was called, no external system was contacted, and no packing, handover or compensation action was executed.