What the documents look like
Advertising delivery adjusts prices against traffic and conversion in real time, so the work does not wait on platform campaign review. The people involved—delivery specialists, brand marketing teams, and agency operators—move between Juliang Qianchuan, JD Kuaiche, Alimama, and store transaction data, with daily or hourly updates that make handovers frequent. At the conversation logs and audit step, the materials are delivery plans, keyword reports, audience package descriptions, and conversion attribution tables. These materials record who started which conversation, at what time, under which identity.
The materials themselves do not grant authorization. Retrieval and form collection supply values that still need to be checked against the business record. A conversation identity is confirmed by matching chatId to the target conversation and the business record; sessions from different entry points are not combined into one count. When run details are needed, the official contract requires setting detail and inspecting responseData, and business data that is not returned cannot be treated as fully retained. Identity fields in test mode may differ from a formal call, so input, history, and returned content are checked separately. Reconciliation, retention, and compliance requirements are carried out by a complete business plan; the existence of a log does not mean a compliance audit is finished.
Hypothetical paper exercise: the source material reads, "From 1 March 2025 to 31 March 2025, delivery group A used the API Key of application X to create sessions for keyword report checks; the session chatId is recorded as adgroupA-0312; during this period the attribution table was maintained by operations group B." The sentence to be assessed is, "Delivery group A has obtained write authorization for operations group B's attribution table." That sentence concerns a subject, an object, a period, and a scope of permission. The material states no authorization clause, so the sentence is unsupported and remains pending verification. It does not constitute a denial of permission.
Constraints at the conversation logs step
The conversation interface is authenticated with 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, and body.appId is then not required. The appId priority order is body.appId, then <apiKey>-<appId>, then the appId associated with the apikey under the older adaptation. Some SDKs need a v1 path on BaseUrl and some do not; a 404 can be retried with v1 added.
To proxy team member identity through authProxy, the team owner must enable authProxy when creating or editing that key, and the proxied identity still needs permission for the target application and conversation. This applies only to FastGPT >= v4.15.0. The model, temperature, and similar fields passed in are invalid; the orchestration decides them and they do not change with API parameters. Actual Token consumption is not returned; setting detail=true and manually computing the tokens value inside responseData is the documented route.
For chatId: when it is absent, the context feature provided by FastGPT is not used and context is built entirely from the passed messages. When it is a non-empty string, the conversation is conducted under that chatId, the session is taken automatically from the FastGPT database, and the last item of the messages array is used as the user question while the remaining messages are ignored. The caller ensures chatId uniqueness, with a length under 250, typically the dialog ID of its own system.
For responseChatItemId: if passed, it becomes the ID of the response message for this conversation and FastGPT stores it in the database automatically. It must be unique under the current chatId. For detail, the intermediate values (module status, complete response result) are returned; in stream mode they are distinguished by event, and in non-stream mode the result is held in responseData. For variables, this is a module variable object that replaces [key] in module input content.
The conversation CRUD section names the key fields: appId is the application ID, chatId is the ID of one conversation under an application, and dataId is the ID of one exchange under a conversation. The session list query uses source=api to get sessions created through the API and does not get sessions from the page. Clearing application sessions likewise clears only sessions created through the API Key, not sessions from online use, share links, or other sources.
When a workflow contains an interactive node, the same interface is called with detail=true. In stream=true, the interactive node configuration is obtained from data.interactive under event=interactive. In stream=false, it is obtained from the element containing the interactive field inside choices[].message.content. The interactive returned to the external caller is a display configuration containing only type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs, and nodeResponseId are not returned. If an internal children, loop, or tool wrapper interaction is hit, the interface returns the deepest user-facing interactive node. For a user selection, the result is passed directly as a message. For form input, the entered content is serialized as an object into a string and used as the messages value, with keys matching the form keys, and chatId must stay consistent.
For plugin requests, the interface matches the conversation interface with a few differences: the interface defaults to detail mode, chatId is not required because a plugin runs only one round, messages are not required, variables carry the plugin input, and pluginData carries the plugin output. The plugin output can be found in the responseData element with moduleType=pluginOutput, whose pluginOutput is the plugin output.
The question-guide interface after 4.8.16 requires appId and chatId. The system pulls the most recent 6 rounds of conversation under that chatId as context to guide the answer. If questionGuide is not passed, the latest published configuration is taken according to appId.
Configuration and implementation checks
The table below is tied to the hypothetical exercise above and lists officially documented settings or implementation checks relevant to this page and its primary task. The values are starting points for this hypothetical trial, used for comparison against a control value, and are not official defaults.
| Configuration or check | Hypothetical starting point and reason | Comparison object and observation |
|---|---|---|
| body.appId and authentication | The exercise calls with an API Key and passes appId in the request body first | Compare with the appId associated with the key; confirm whether they match |
| chatId | The exercise records adgroupA-0312, length under 250 | Compare with the conversation identifier in the attribution table record |
| detail | The exercise needs run details, so set to true | Compare with whether responseData appears in the response |
| source | The session list query uses source=api | Compare with page-origin sessions; confirm the scope difference |
| responseChatItemId | The exercise sets it as unique under the same chatId | Compare with existing response IDs; a duplicate requires replacement |
| authProxy | The exercise involves member identity proxying, which the team owner must enable | Compare with target application and conversation permission; insufficient permission fails the check |
Three common errors
- Treating the same chatId as the same permission. In the exercise chatId is adgroupA-0312, which identifies a conversation only and states no write permission for the attribution table. The judgment follows a comparison with the authorization material.
- Treating responseData returned under detail=true as complete business retention. The exercise asks only for run details; fields that are not returned remain unknown and are checked one by one.
- Merging API-origin sessions with page sessions in one count. source=api retrieves only sessions created through the API; when compared with page-origin sessions they are recorded separately.
How to verify the setup
- Input the exercise source material and the sentence to be assessed. Compare the four items—subject, object, period, and scope of permission—for the same source and the same field. The condition is met only when an authorization clause explicitly states write permission; otherwise the result is recorded as pending verification.
- Input the exercise request parameters. Compare body.appId with the key-associated appId and chatId with the attribution table record. Observe whether responseData appears in the response. Its appearance satisfies the condition that detail took effect.
- Input the session list query with source=api. Compare the returned list with page-origin sessions. Observe whether total covers only API-origin sessions; consistent coverage satisfies the condition.