What the documents look like
A Shopify standalone store is configured by the merchant. Payment, shipping fees, and fulfillment services are set up by the merchant rather than unified under a single platform, and returns are not automatically processed by a platform-wide mechanism. Compared with a TikTok Shop US store, the merchant carries more of the configuration work directly.
The documents handled day to day are order details, shipping fee templates, shipping labels, and refund records. These materials sit across Shopify Admin, payment gateways, carrier systems, and inventory location data. The HTTP integration step is where values returned by external systems are brought into a conversation flow. Data updates per order and daily, which means an integration built for this task is checked against each individual order and against daily records rather than against a single bulk state.
For after-sales questions, the practical consequence is that the merchant decides what the external system returns and what the conversation flow does with it. The HTTP module does not decide business outcomes on its own. A carrier status, a refund record, and a shipping fee template each come from a different place, and the integration only carries values between them.
Constraints at the HTTP integrations step
The HTTP module sends a request to a corresponding address. Params are used for path parameters, Body is used for the request body, Headers carry special information, and all three can reference variables through {{}}. The URL can also reference variables. Variables come from global variables, system variables, and outputs of preceding nodes.
Return values are extracted through JSON path syntax. The configured key follows JavaScript object access rules. After v4.6.8, output formatting was added: when the output type is set to string, the value of the corresponding key is converted into a JSON string. This means the HTTP module can pass values onward to a text processing step and then into a chat step.
The chat interface uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended. For compatibility with the OpenAI SDK, Authorization: Bearer <apiKey>-<appId> is also supported, and in that case body.appId is not required. The priority order for appId is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. The model, temperature, and similar parameter fields passed in are invalid; these are determined by the orchestration and do not change with API parameters. Actual consumed Token values are not returned. Setting detail=true allows manual calculation of the tokens value inside responseData. chatId does not exist in test mode, and responseChatItemId likewise does not exist in test mode. Using authProxy to proxy a team member identity requires the team owner to enable authProxy when creating or editing that key, and the proxied identity still needs permission for the target application and conversation.
A hypothetical drill sample is used for checking below. A standalone store operator submits material to be checked. The source text reads: "Order A was created on 10 March 2025, its status is shipped, and the carrier system returned tracking number SF123456789. The refund record shows that this order has no refund request." A separate draft handover request reads: "Please synchronize the fulfillment status of Order A to the external system and confirm that the refund record is empty."
The material carries the subject, the object, the status, and the date scope needed for a check. The draft handover request asks for a business action and a confirmation. Neither is an approval, an execution, or a completed synchronization.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this sample | Reason and comparison method |
|---|---|---|
| URL | Address filled in according to the external interface document | The address can reference variables; compare it against the external interface contract |
| Request method | Selected according to the external interface document | Compare against the method declared in the external interface document |
| Headers | Authorization: Bearer {{token}} | Credentials are injected through secure configuration and are not written into public samples |
| Body | JSON constructed according to the external interface contract | Takes effect only under the corresponding request type; check the field structure |
| Variable reference | Reference to the output of a preceding node | Check each actual passed value against the node output |
| Return value extraction | Key configured to correspond to a JSON path | Follows JavaScript object access rules; compare against the interface response structure |
The starting points above are hypothetical choices for this sample. They are not official defaults and no numeric limit is assumed. The comparison method for each row is what determines whether the setting matches the external interface contract.
Three common errors
- Treating a
chatIdorresponseChatItemIdthat does not exist in test mode as a business fault. The input is a test-mode request; the comparison object is the documented condition that these fields do not exist in test mode; the observable result is whether the empty value is misjudged as a fault. - Confusing behavior the node already has with a business action that requires a separately connected system. The input is the draft handover request; the comparison object is the documented scope of node behavior; the observable result is whether synchronizing the external system is treated as something the node completes automatically.
- Treating a value collected by retrieval or by a form as the basis for authorized execution. The input is form input content; the comparison object is the documented statement that forms collect values; the observable result is whether the form value is taken directly as authorization to execute.
How to verify the setup
- Input the source text and the draft handover request from the hypothetical drill sample above. Compare whether the draft sentence shares the same subject, the same period, and the same field as the source text. The condition is met when no judgment appears that is unsupported by the source or still pending verification. A draft that asserts synchronization has occurred, or that treats the empty refund record as confirmed, does not meet the condition.
- Input a variable configuration that references the output of a preceding node. Compare the actual passed value against the node output value. The condition is met when the two are consistent. If they are not consistent, record the gap and do not claim that a test was performed.
- Input a request with
detail=true. Compare whetherresponseDatacontains atokensvalue. The condition is met when the value can be manually calculated from what is returned. Do not claim that this was actually executed. If the field is absent, the result remains unknown and the gap is recorded.
These checks test the named primary task: whether material and a draft handover request are handled within the documented scope of the HTTP integration step, and whether values collected by retrieval or by a form are kept distinct from authorization to execute a business action. Retrieval is not authorization. A pending request is not approval. An offered option is not execution.