What the documents look like
Promotion enrollment and price management for marketplace stores moves through four working papers: the activity enrollment form, the promotional price approval sheet, the inventory lock sheet, and the activity review sheet. In the order fulfillment and after-sales question stage, the operating team reconciles enrollment records, approval status, locked inventory quantities, and transaction prices. The material identities that matter here are the approval sheet as the authorization document, the enrollment form as the object record, the inventory lock sheet as the quantity scope, and the review sheet as the later reconciliation record.
Data sources named in the category brief are the Tmall marketing backend, the JD activity backend, ERP inventory, and historical transaction prices. Updates occur weekly or per activity. The category brief rates its own confidence as roughly accurate, so the data-source list is treated as context rather than as a verified inventory of live systems.
The HTTP request node sends a request to a configured address. Params carry path parameters, Headers carry request headers, and Body carries the request body. All three can reference variables through {{}}, and the URL can also reference a variable. Variables come from global variables, system variables, and upstream node outputs. The chatId and responseChatItemId system variables do not exist in test mode. Return values are extracted through JSON path, and when the output type is set to string, the value at the corresponding key is converted into a JSON string.
The chat completions interface uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended; the Authorization Bearer apiKey-appId form is supported for OpenAI SDK compatibility. The appId priority order is body.appId, then apiKey-appId, then the appId associated with the API key under the older adaptation. The model and temperature parameters passed in are invalid because the orchestration decides them. The authProxy setting for proxying team member identity requires the team owner to enable it when creating or editing the key, and the proxied identity still needs permission on the target application and conversation. Retrieval and forms collect values; business verification, approval, database writes, and external synchronization each need their own downstream implementation.
Constraints at the HTTP integrations step
The approval sheet is the authorization document for this category. A pending approval status does not authorize any downstream synchronization or inventory lock. The order fulfillment and after-sales question stage therefore begins with a status check on the approval sheet before any HTTP request is constructed.
The HTTP node can reference variables, but variable reference is not business verification. A promotional price value taken from a form or from retrieval remains an unverified value until a downstream step checks it. The chat completions interface does not return actual Token consumption; setting detail=true returns responseData with tokens values that can be calculated manually. The interface does not return an approval decision, does not write to ERP, and does not lock inventory.
The authProxy setting is documented as requiring the team owner to enable it, and the proxied identity still needs permission on the target application and conversation. A request that carries a valid API key does not by itself establish that the caller is authorized for the specific object in the approval sheet.
The chatId and responseChatItemId system variables are absent in test mode. A missing chatId during debugging is a test-mode condition, not a business fault. The sample below does not provide a chatId, so that field remains unknown.
Configuration and implementation checks
The following hypothetical drill sample is used throughout this section. It is a paper sample, not a real record.
Hypothetical drill sample: a brand sales planner submits a promotional price approval sheet with the text: "Activity object: product A; enrollment channel: Tmall marketing backend; promotional price: 99 yuan; inventory lock: 200 units; approval status is pending review; validity: March 1 to March 7." A separate handover request reads: "Please synchronize this approval sheet to ERP through the HTTP interface and lock inventory."
| Configuration item | Value or check content | Relation to the sample |
|---|---|---|
| Request address and method | Chosen according to the external interface document; the address can reference a variable | The ERP interface address is not provided in the sample and remains unknown |
| Headers authentication | Authorization injected through secure configuration | Credentials are not written into a public sample |
| Body structure | Used only under the corresponding request type; check the JSON contract | Approval sheet fields need one-to-one correspondence with ERP fields |
| Variable reference | References global variables, system variables, and upstream node outputs | Promotional price and inventory lock values checked item by item |
| Return value extraction | Extracted by JSON path; output type can be string | Check the lock result field returned by ERP |
| chatId status | Absent in test mode; not used as a business judgment basis | The sample provides no chatId, so it remains unknown |
The request address and method are a configuration choice that follows the external interface document. The sample does not provide an ERP interface address, so that value is unknown and cannot be filled in by assumption. The Body structure is used only under the corresponding request type. The promotional price of 99 yuan and the inventory lock of 200 units are the two values that must be checked against the ERP contract fields. The approval status of pending review is the authorization boundary for the sample. The validity period of March 1 to March 7 is a date scope, not a supply term.
Three common errors
- Treating the pending review status on the approval sheet as an approval and triggering the synchronization request. The sample approval status is pending review, and no authorization to execute has been given. The handover request asks for synchronization and inventory lock, but the approval document does not authorize that action.
- Treating the promotional price and inventory lock values collected by a form or retrieval as verified data written into ERP. Forms collect values. Business verification and database writes need their stated downstream implementation. The 99 yuan price and 200 unit lock are collected values in the sample, not verified values.
- Treating a string extracted from the HTTP node return value as business confirmation. The return value represents the parsing result of the interface response. It does not represent that approval occurred or that inventory lock completed. A returned lock result field, if present, is a response field, not an approval record.
How to verify the setup
- Input the sample approval sheet text and the handover request. Compare the approval status field against the authorization boundary. The continuation condition is met only when the approval status is explicitly approved and the authorization scope covers the stated object. A pending review status is recorded as not authorized. The sample records pending review, so the synchronization request is not authorized at this stage.
- Input the promotional price and inventory lock values referenced in the Body. Compare them against the ERP interface contract fields. The request construction condition is met only when field names, types, and values correspond item by item. Missing fields are recorded as unsupported. The sample does not provide the ERP contract, so the correspondence remains unknown and cannot be asserted.
- Input the ERP return value and extract the lock result field by JSON path. The extraction condition is met only when the corresponding field exists in the returned structure and its value can be parsed. When the return is empty or the field is missing, record the result as pending verification and do not assert a failure cause. The sample does not provide an ERP return value, so this check remains an open case with no observable result.
Across all three checks, a pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination. Missing evidence remains missing.