What the documents look like
Amazon FBM fulfillment and after-sales question handling draws on Amazon Seller Central, carrier systems, ERP orders and customer service email. The working documents are the order picking list, the shipment confirmation, the return address setting and the logistics tracking sheet; updates arrive per order and daily. For the HTTP integration step, these materials decide what may be transmitted to an external system and what still awaits confirmation.
The picking list supplies the picking scope. The shipment confirmation records the shipment fact. The logistics tracking sheet carries the tracking number returned by the carrier. The return address setting shapes the after-sales reply. When an HTTP call writes an unconfirmed tracking number into a shipment confirmation, or sends an unreviewed return address outward, the documented consequences are order cancellation, A-to-z claims and a decline in store performance.
A paper exercise sample is used below. The order picking list reads: "Order A-1001, picking scope 1 March 2025 to 5 March 2025, carrier undecided, tracking number field blank." The shipment confirmation reads: "Order A-1001, shipment status is pending confirmation, tracking number: not returned." The customer service email reads: "Buyer asks for the return address; the store return address setting has not been reviewed." The draft sentence under judgement is: "Order A-1001 shipped on 2 March, the tracking number has been returned, and the return address is in effect." The subject is order A-1001; the objects are shipment and return address; the states are pending confirmation and not yet reviewed. The draft sentence is not supported by the materials.
Constraints at the HTTP integrations step
The HTTP module sends a request to a target address. Params carry path request parameters, Body carries the request body for POST and PUT, and Headers carry special information. All three may reference variables through {{}}, and the URL may also reference variables. Variables come from global variables, system variables and preceding node outputs. System variables include appId, chatId, responseChatItemId, variables, cTime and histories; histories defaults to at most 10 entries and its length cannot be modified. Return values are extracted through JSON path syntax, and when the output type is set to string, the value of the corresponding key is converted into a JSON string.
The chat/completions interface uses APIKey authentication. Passing body.appId in the request body is recommended, and Authorization: Bearer <apiKey>-<appId> is also supported, in which case body.appId need not be passed. Some SDKs need a v1 path on BaseUrl and some do not; if a 404 appears, adding v1 and retrying is the documented step. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. Passed fields such as model and temperature have no effect because the orchestration decides them. chatId and responseChatItemId do not exist in test mode. With detail=true, intermediate values are returned; an interactive node exposes only type and params, while entryNodeIds, memoryEdges, nodeOutputs and nodeResponseId are not returned.
These constraints mean the integration step can transmit what a preceding node or a variable supplies, and it can extract a value from a response. It cannot turn a pending shipment status into a shipped status, and it cannot turn an unreviewed return address setting into an effective one. Retrieval or a form does not perform authorization. Business verification, approval, database writes and external synchronization each need their own downstream implementation.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point for this page | Reason and comparison method |
|---|---|---|
| Request address | Carrier query interface address | Compare path and method word by word against the external interface document |
| Params | Order number A-1001 | Compare against the order number in the picking list text |
| Headers | Authorization: Bearer credential | Check that the authentication header is injected; the credential is not written into the sample |
| Body | Order number and date range | Compare against picking scope 1 March 2025 to 5 March 2025 |
| Return value extraction | Tracking number field | Compare against the tracking number field in the shipment confirmation |
| chatId | Hypothetical session identifier for this exercise | Check that it is non-empty and shorter than 250, and that it does not exist in test mode |
The starting points above are hypothetical trial values chosen for this page. They are not official defaults. The comparison method for each row is the check that decides whether the value matches the source material.
Three common errors
- Treating a pending shipment status as shipped and writing it into the shipment confirmation. The check input is the shipment confirmation text "shipment status is pending confirmation"; the comparison is the draft sentence "shipped on 2 March"; the observable result is that the status field does not match.
- Treating a blank tracking number field as returned. The check input is the shipment confirmation text "tracking number: not returned"; the comparison is the draft sentence "the tracking number has been returned"; the observable result is that the tracking number field is absent.
- Treating an unreviewed return address setting as in effect. The check input is the customer service email text "the store return address setting has not been reviewed"; the comparison is the draft sentence "the return address is in effect"; the observable result is that the review state is not complete.
How to verify the setup
- Input the hypothetical picking list text "Order A-1001, picking scope 1 March 2025 to 5 March 2025". Compare the order number and date range in the request Params against that text. Observe whether the two are identical word by word. If they are not, record the input as not matching and do not continue the judgement.
- Input the shipment confirmation text "shipment status is pending confirmation, tracking number: not returned". Compare the tracking number field produced by the return value extraction. Observe whether that field is empty. If it is empty, record the value as not returned; do not treat the empty value as a business fault.
- Input the customer service email text "the store return address setting has not been reviewed". Compare the draft sentence "the return address is in effect". Observe whether the review state is complete. If it is not complete, record the item as pending verification; do not supply an authorization or effectiveness clause to obtain a definite answer.
A pending request is not an approval. An offered option is not an execution. An unsigned termination is not a completed termination. Where the material does not state a field, the value remains unknown. A similarity score is not a category, entity or permission filter, and retrieval is not authorization.