What the documents look like
Short-video affiliate distribution relies on long-term content exposure and product-link conversion rather than live explanation. The working records for operating reports and exception reviews therefore sit in the affiliate selection pool, short-video playback data, product transaction data and platform rules, and they refresh on a daily and weekly basis. The documents handled day to day include short-video scripts, attached-product lists, commission plans and violation feedback. These materials set the reporting scope and the exception boundary. At the integration layer, the HTTP module sends a request to a given address and returns a response; it does not decide whether a commission plan is approved, whether a product may be promoted, or whether a record is authorized for use.
A short-video script, an attached-product list, a commission plan and a violation feedback entry each carry different fields. A commission plan may show a review status. A violation feedback entry may be empty. A product list may name a product and a publication date. The integration step retrieves and parses what an external system returns. The business meaning of those fields is read from the source documents, not inferred from the fact that a request succeeded.
Constraints at the HTTP integrations step
The HTTP module sends a request to the corresponding address. Params carry path 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 for special information. All three can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables and the output of preceding nodes.
System variables include appId, chatId, responseChatItemId, variables, cTime and histories. The histories variable keeps a default of at most 10 entries and its length cannot be modified. In test mode, chatId and responseChatItemId do not exist, so reading empty values there matches the documented condition rather than indicating a business fault.
Return values are configured to describe how the interface response is parsed, using JSON path syntax to extract values. When the output type is set to string, the value at the corresponding key is converted into a json string. This is a parsing setting, not a permission setting and not a business approval.
The chat completions interface uses APIKey authentication. When calling chat/completions, passing body.appId in the request body is recommended. The form Authorization: Bearer <apiKey>-<appId> is also supported for OpenAI SDK compatibility, and in that case body.appId is not needed. Some SDKs need v1 added to BaseUrl and some do not; if a 404 appears, adding v1 and retrying is the documented step. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation.
To proxy a team member identity through authProxy, the team owner must enable authProxy when creating or editing that key. The proxied identity still needs permission on the target application and conversation. This applies only to FastGPT versions at or above v4.15.0. The model, temperature and similar fields passed in are ineffective because the orchestration decides them. The interface does not return the actually consumed Token value; setting detail=true allows manual calculation from the tokens value inside responseData. When detail=true, intermediate values such as module status and the complete response are kept in responseData, and in stream mode they are distinguished through event.
A hypothetical paper exercise sample: on 3 June 2025 a content operator compiles an attached-product list. The source text reads: "Product A's attached-video was published on 1 June; the commission plan status is pending review; the violation feedback field is empty." A proposed handover sentence reads: "Product A's commission plan is in effect and may be counted in this week's operating report." This sample is used only to compare the fields retrieved by the interface against the handover wording. It does not represent any real business action.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point | Reason and comparison object |
|---|---|---|
| Request address and method | Fill in per the external interface document; the address references the output of a preceding node | Compare character by character against the path and method given in the interface document |
| Headers authentication | Authorization uses the Bearer form; credentials are injected by security configuration | Compare against the two authentication forms in the key usage rules |
| Body structure | Write JSON per the external interface contract; string variables take quotation marks | Compare against the quotation rule in the Body declaration example |
| Return value extraction | Configure key and output type per JSON path | Compare against the field paths in the interface response example |
| Variable source | Label each item as global variable, system variable or preceding node output | Compare against the system variable description list |
| Debug identity fields | In test mode chatId and responseChatItemId are empty | Compare against the non-empty values passed in a formal call |
These starting points are used for this hypothetical trial and are not official default values.
Three common errors
- Writing a pending-review status as already in effect. The input is the same product and the same field. The source text states the commission plan status is pending review, while the proposed sentence says "in effect". The comparison object is the status value in the source text. The observable result is that the proposed sentence and the source value are mutually exclusive on the same subject, the same period and the same field.
- Treating an empty chatId in test mode as a business fault. The input is the empty value returned in test mode. The comparison object is the documented condition that chatId does not exist in test mode. The observable result is that the empty value matches the documented condition and does not constitute evidence of a fault.
- Treating a record retrieved over HTTP as an authorization result. The input is the product record returned by the interface. The comparison object is the authorization status field held on the business side. The observable result is that the retrieved record does not itself carry an authorization conclusion, and a separate system implementation is needed to verify it.
How to verify the setup
- Take the source text "the commission plan status is pending review" and compare it word by word against the proposed sentence "in effect". When the same subject, the same period and the same field show mutually exclusive values, record a wording conflict. When the source text does not state an effective time or an approval conclusion, record the item as pending verification rather than as a negation.
- Send one request in test mode and observe the returned values of chatId and responseChatItemId. Compared against the system variable description, both being empty matches the documented condition. In a formal call, a non-empty chatId should be passed in, and responseChatItemId should remain unique under the current chatId.
- Use the paper input
[]to check the downstream design for handling an empty result, and observe whether the downstream takes the empty-list branch. This check verifies only the empty-result handling logic and does not claim that any retrieval rule necessarily returns an empty array. If the interface actually returns non-empty records, record the observed values and keep the pending-verification items.
The pending-review status in the sample does not establish that an operation permission is missing. Signing, reaching cooperation and a contract taking effect are three distinct facts. A quotation validity period does not indicate a supply period. Where the source text is silent, the evidence gap remains open, and no authorization or effective clause should be supplied to reach a definite answer.