What the documents look like
Store price and display checks happen during ordinary trading periods, where the operational focus is sustained execution of a standard rather than onboarding or launch support. The working material comes from supervision systems, POS price tables, store cameras and head-office promotion calendars, and the day-to-day documents are store-visit photographs, price-tag lists, display standards and rectification notices. The task on this page is inventory procurement and supplier records, and those records are frequently exchanged with external systems through HTTP interfaces. The brief gives a weekly or monthly update frequency for this category. That cadence is not used here to infer batch synchronisation, full synchronisation, real-time behaviour or transaction-triggered execution.
Two characteristics shape this step. First, the material that arrives from a supplier or procurement exchange carries a status and an authorised scope, and that status is a business fact rather than a retrieval outcome. A record that appears in a search result or in a submitted form has not thereby been approved, authorised or written to any downstream system. Second, the HTTP module in this platform is manually configured and trigger-executed; it sends a request to an address, and the way the response is read back is a separate configuration decision. Neither of those facts turns a returned document into an authorisation.
Constraints at the HTTP integrations step
The HTTP module can be added repeatedly, is configured by hand and executes when triggered. Params carry path request parameters and are common in GET requests. Body carries the request body and is common in POST and PUT requests. Headers carry request headers used to pass special information. All three can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables and the outputs of preceding nodes. The documented system variables include appId, chatId, responseChatItemId, variables, cTime and histories; histories takes the most recent 10 entries by default and its length cannot be changed.
Return values are configured as a parsing instruction rather than as the interface's own response. A JSON path expression extracts a value from the response, and after FastGPT v4.6.8 an output type of string converts the value at the corresponding key into a JSON string. Keys follow JavaScript object access rules, so a key of data.user.name reads the nested name field, and a key of data.list[1] reads the second element of a list.
For the chat completion interface, authorisation uses an API key. When calling chat/completions, passing body.appId in the request body is recommended; for OpenAI SDK compatibility, Authorization: Bearer <apiKey>-<appId> is also supported, in which case body.appId is not required. Some SDKs need v1 in the BaseUrl and some do not, and a 404 can be retried with v1 added. 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 fields passed in are invalid because the orchestration decides them. Actual token consumption is not returned; setting detail=true and calculating the tokens value inside responseData manually is the documented route. Proxying a team member identity through authProxy 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. This applies to FastGPT v4.15.0 and later.
In test mode, chatId and responseChatItemId do not exist. An empty value for those fields during debugging is an expected condition, not a business fault.
Assumed paper exercise sample. The material text to be checked reads: "Supplier A was entered into the qualified supplier register in the third quarter of the current year, the supply scope is chilled dairy products, and the authorised contact person is B." The draft sentence under review reads: "Supplier A has completed this quarter's inventory procurement authorisation and may place orders." This draft sentence has not been submitted for approval and is a text awaiting determination. No real customer, real company or legitimate identity number is used.
Configuration and implementation checks
The table below is the starting point for this assumed exercise. The values illustrate a comparison method and are not official defaults.
| Configuration item | Assumed starting point for this exercise | How it is checked |
|---|---|---|
| Request method | POST | Compare word by word against the method declared in the external interface document |
| URL | The address given in the external interface document | Confirm the address can reference variables; do not write it into a public sample |
| Headers | Authorization references a secure configuration | Check the credential source and the permission on the target application |
| Body | Takes effect only under the corresponding request type | Check the JSON structure against the external interface contract |
| Return value key | data.user.name | Check item by item under JavaScript object access rules |
| Output type | string | Check whether the value is converted into a JSON string |
The assumed starting point for the request method is chosen because the exercise concerns submitting a supplier record, and the comparison is made against the method the external interface document declares. The return value key is chosen to demonstrate nested extraction, and the comparison is made against the actual response shape. Neither value is presented as a platform default.
Three common errors
- Treating a retrieval result as an authorisation credential. A retrieval library returning supplier material does not mean the supplier has been granted ordering authorisation. The input is the material text above, the comparison object is the authorisation status field, and the observable result is that the authorisation field remains pending review.
- Treating a pending review as a missing operating permission. The material text states only that the supplier is entered in the register; it does not state that authorisation has taken effect. This is an unsupported item, and it cannot be recorded as a negation or as a conflict.
- Treating a debugging empty value as a business failure. In test mode
chatIddoes not exist, so an empty input is expected. The comparison object is the run-mode marker.
How to verify the setup
- Input the material text and the draft sentence given above. Compare whether "has completed authorisation" in the draft sentence and "entered into the qualified supplier register" in the original text share the same subject, the same period and the same field. If the original text does not state that authorisation has taken effect, record the draft sentence as unsupported. The expected observation is that the authorisation status remains pending review; this is a paper determination and no test has been run.
- Input a POST request carrying a Body. Compare the JSON structure of the request body against the external interface contract. If a field type or nesting level does not match, record it as needing correction. The expected observation is a structural mismatch or a structural match; no live request is claimed.
- Input a conversation request in test mode. Compare whether
chatIdandresponseChatItemIdare present. If they are empty, record it as an expected debugging condition and do not determine it to be a business failure. The expected observation is an empty value for those fields under test mode.
In each case, the material must sit inside a retrieval scope the operator has access to, or inside a clearly identified manual input. Where it is missing, record the gap rather than supplying an authorisation or an effective clause to reach a definite answer. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination.