What the documents look like
Category access work happens before a listing goes live or a store is onboarded. The objects under review are the operating entity's qualifications and the authorization chain behind them. The working materials are business licenses, trademark registration certificates, brand authorization chains, and industry-specific permits. These materials come from platform recruitment pages, the national enterprise credit information publicity system, trademark office data, and permit systems. They update irregularly and are reassembled for every onboarding attempt.
For operating reports and exception reviews, the questions are narrow: which material was submitted at which step, by which subject acting in which capacity, in what status, and whether that material can support publishing in the target category. HTTP integrations sit at the point where a workflow calls an external system, extracts a response value, and hands a result to a downstream step. Retrieval and form collection produce values; they do not perform authorization.
Constraints at the HTTP integrations step
The HTTP module sends a request to a given address. Params carry path parameters and are used most often with GET requests. Body carries the request body and is used most often with POST and PUT requests. Headers carry special information. All three can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables, and prior node outputs.
System variables include appId, chatId, responseChatItemId, variables, cTime, and histories. Histories default to at most 10 entries and the length cannot be changed. chatId and responseChatItemId do not exist in test mode. Return values are extracted from the interface response by JSON path, and when the output type is set to string, the value for the corresponding key is converted to a JSON string.
The chat completions interface uses APIKey authentication. Passing body.appId in the request body is recommended. Authorization: Bearer <apiKey>-<appId> is also supported, in which case body.appId is not needed. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. Passed model and temperature fields have no effect because the orchestration decides those values. With detail=true, intermediate values are returned; in non-stream mode the result is stored in responseData. Using authProxy to act on behalf of a team member requires the team owner to enable it when creating or editing the key, and the proxied identity still needs permission on the target app and conversation.
Hypothetical paper exercise. Source text for review: "Company A holds trademark registration certificate No. 12345678, covering goods in Class 25 clothing. Company B issued a letter of authorization permitting Company C to sell Class 25 clothing on a given platform from January 1, 2025 to December 31, 2025; the authorization letter is dated December 20, 2024. No document showing that Company A granted Company B the right to sublicense was found." Handover request to be assessed: "Use the HTTP interface to mark Company C's Class 25 clothing category access status as authorized and write the authorization chain into the external system."
Configuration and implementation checks
| Configuration item | Hypothetical starting value for this exercise | Reason and comparison method |
|---|---|---|
| Request address | The address given in the external interface document, including {{BaseUrl}} | Compare character by character against the address listed in the interface document |
| Request method | Chosen according to the external interface contract | Compare against the method stated in the interface document |
| Headers authentication | Bearer {{token}} | Compare against the key usage rules and confirm the credential source |
| Body structure | JSON built according to the external interface contract | Compare field by field against the interface document |
| Return value extraction | Key configured by JSON path | Compare the extraction result against the interface response example |
| Output type | String | Compare against the type required by the downstream node |
The values above are starting points for this hypothetical exercise. They are not official default values.
Three common errors
- Treating the handover request as an established authorization. In the sample, the authorization letter was issued by Company B, and no document showing that Company A granted Company B sublicensing rights was found. Company C's category access status lacks a complete authorization chain. The check is to compare the subject names and the levels of authorization, and observe whether the chain closes.
- Treating a value obtained through retrieval or form collection as an executed authorization. The HTTP module can send a request and extract a return value; the extracted value does not change the authorization status in the external system. The check is to compare the request body content against the actual write result, and observe whether the external system returns a success indicator.
- Treating an empty chatId in test mode as a business fault. The documentation states that chatId does not exist in test mode. The check is to compare the chatId value in test mode against a production call, and observe whether the missing field is caused by the mode difference.
How to verify the setup
- Input the sample source text and the handover request. Compare the issuing subject on the authorization letter against the holder on the trademark registration certificate, and observe whether the authorization chain shows a break. If the existence of a sublicensing document cannot be confirmed, record it as an evidence gap and do not judge the status as authorized.
- Input a request built according to the interface document. Compare the actual values of appId, chatId, and messages in the request body against the documented descriptions, and observe whether the return value extraction result corresponds to the JSON path in the interface response example. Do not assume a first-hit match or full recall.
- Input an empty result array
[]to check the downstream design. Compare how the downstream node handles an empty value, and observe whether undefined behavior appears. This check verifies downstream design only and does not claim that retrieval will necessarily return an empty result.