What the documents look like
Retail checkout and loyalty work in this category covers order fulfilment and after-sales answers built around four document types: promotional price tags, membership points rules, the daily checkout report, and exception refund slips. The distinguishing point against convenience-store fresh-food ordering is that this category turns on price and member benefit rather than short-shelf-life stock. Data comes from the POS system, the member CRM, the payment platform, and the price-tag system, with updates at daily or per-shift frequency. The HTTP integration step has to align the external request address, method, parameters, authentication, and response parsing against those same documents one item at a time, because a mismatch can surface as a price complaint, a cash shortfall or overage, or a member-benefit dispute.
The HTTP module sends a request to a given address. Params, Body, Headers, and the URL can reference variables through {{}}, and those variables come from global variables, system variables, or upstream node outputs. Response values are extracted with JSON path syntax; when the output type is set to string, the value for that key is converted into a JSON string. chatId and responseChatItemId are session system variables and do not exist in test mode, so they cannot be treated as fields an external refund interface must return. The appId, detail, and stream parameters of the FastGPT chat API are checked separately under that API. Retrieval and forms do not grant refund or synchronization authorization.
A hypothetical drill sample is used below. A store checkout supervisor, at shift handover on 12 March 2025, holds a promotional price tag whose text reads "12 March, member price 9.9 yuan storewide; receipt prints original price 12.9 yuan and member discount 3 yuan," together with an exception refund slip whose text reads "12 March 14:20, order number A-0312-14, refund amount 9.9 yuan, status pending review." The draft sentence to be judged is "this refund has been completed at the member price and synchronized to the member CRM." Judging that sentence requires comparing whether the refund slip status field states completion and whether the member CRM record states that it received this entry. Pending review does not equal completed execution, and an unstated synchronization result remains unknown.
Constraints at the HTTP integrations step
The request address and method depend on the external interface contract, and the address may reference a variable. Headers carry authentication; the Authorization header uses Bearer plus a credential variable, and the credential injection point is checked without writing the credential into a public sample. Body applies only under the request types where it takes effect, and its JSON structure is checked against the external contract, including field names, types, and required conditions. Variable references draw on global variables, system variables, and upstream node outputs, and the actual passed values are checked item by item. Response parsing uses JSON path to extract values, with the output type chosen as needed, and the configured key is checked against the response structure.
The debug identity fields matter at this step. chatId and responseChatItemId do not exist in test mode, so an empty value there is not a business fault. The external refund interface response is checked separately against its own contract, and the absence of a field in a response does not by itself establish the running mode. Nothing in the supplied documents states a scheduled trigger, a hidden control, or an automatic business action, so none is assumed here.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this drill | How to check |
|---|---|---|
| Request address and method | Filled in per the external interface document; the address may reference a variable | Compare word by word against the external interface contract |
| Headers authentication | Authorization uses Bearer plus a credential variable | Check the credential injection point; do not write it into a public sample |
| Body structure | Confirmed per the chosen request method and the external contract; check the JSON structure | Check field names, types, and required conditions |
| Variable references | Reference global variables, system variables, or upstream node outputs | Check the actual passed value for each item |
| Response parsing | Extract response values with JSON path; choose the output type as needed | Check that the key matches the response structure |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | Do not treat a debug empty value as a business fault |
The reason for these hypothetical starting points is that the request address and method, the Body structure, and response parsing all depend on the external interface document and cannot be preset to a fixed value, while variable references and debug identity fields depend on the current orchestration and running mode. Every starting point must be compared against the external interface contract or the actual running mode, and none of them constitutes an official default value.
Three common errors
- Treating the return-value configuration as the interface return value itself. The return-value configuration extracts a response value through JSON path; treating the extraction key as the interface field directly produces a result that does not match the response structure. Check: input a response example, compare the configured key against the JSON path extraction result, and observe whether the output matches the expected field.
- Treating a node's missing debug identity variable as an external business fault. First check the running mode and the available system variables; in test mode these two variables do not exist per the document, and the external refund interface response is still checked separately against its contract. A missing field in the response does not by itself establish the running mode.
- Treating a pending-review status as a completed refund. In the hypothetical drill sample the refund slip status is pending review. Check: input that refund slip text, compare the status field value against the wording "completed," and observe whether the status field states completion; when it does not, record the item as pending verification.
How to verify the setup
- Input the promotional price tag text and the draft sentence from the hypothetical drill sample, compare the draft sentence "completed at the member price and synchronized to the member CRM" against the refund slip status field and the member CRM record, and observe whether the refund slip status states completion and whether the member CRM states that it received the entry. When neither is stated, the sentence is not supported.
- Input the exception refund slip text from the hypothetical drill sample, compare the status field value against the wording "completed," and observe whether the status field clearly states completion. When it states only pending review, record the item as pending verification and do not judge it as completed or not completed.
- After the interface provider supplies a response example, check whether the JSON path exists and whether the extracted value and output type match the downstream agreement. No response example is supplied at present, so the parsing configuration remains pending verification; a path or type mismatch cannot by itself establish an external interface fault.
These verification steps describe expected observations only and do not state that any test was actually executed. Missing evidence remains missing, pending review does not constitute approval, and an unstated synchronization result remains unknown.