What the documents look like
Advertising delivery adjusts prices in real time according to traffic and conversion, and specialists align spend and store transaction data from sources such as Juliang Qianchuan, JD Kuiche and Alimama against delivery plans, keyword reports, audience package descriptions and conversion attribution tables. The conversation logs and audit step handles application-side session records: session titles, conversation lists, single-conversation run details and feedback marks. These records can reflect the dialogue process behind one attribution inquiry or anomaly review, and they do not replace the spend and transaction data held by the delivery platforms themselves. The data updates by day and by hour; this page does not cover batch synchronization or real-time trigger mechanisms.
Sessions are located by appId and chatId, and conversations are located by dataId. When checking a delivery reconciliation inquiry, first confirm which application and which entry a target session belongs to, so that sessions from different entries are not counted as one batch of business records. When run details are needed, set detail in the conversation interface request according to the official contract and read module status and complete results from responseData; non-streaming results are stored in responseData, and streaming results are distinguished through event. Which fields the interface actually returns is the basis, and business data that is not returned cannot be presumed to be fully retained. Identity fields under test mode may differ from formal calls, and inputs, history and returned content must be checked separately. The existence of a log only shows that a record is queryable; reconciliation, retention and compliance requirements are still implemented separately by the complete business plan.
Hypothetical exercise sample. Source text one: an application has appId A1 and a session chatId C9; the session was created through the API, and the conversation list returns two records, of which the AI record has totalRunningTime 2.42. Source text two: under this session, one conversation has dataId D7, and its run details responseData contains one element whose moduleType is chatNode, whose query is "This week's Kuiche spend versus transaction difference", and whose runningTime is 1.22. Draft sentence to be judged: "Session C9 has fully retained all spend details of Kuiche for this week and can be used directly for budget adjustment approval." The checked material does not state a spend-detail field and does not state approval authorization, so this sentence is not supported.
Constraints at the conversation logs step
The conversation interface request carries appId and chatId to locate the target application and session, and the run details of a single conversation are obtained with appId, chatId and dataId. The session list request carries appId, offset, pageSize and source; when source is api, only sessions created through the API are obtained. The conversation list request carries appId, chatId, offset, pageSize and optionally loadCustomFeedbacks to read custom feedback. The run detail request returns responseData, and the fields actually present there are the fields available for checking.
The detail parameter controls whether intermediate values are returned. In non-streaming mode the complete result is stored in responseData; in streaming mode the result is distinguished through event. The event values documented for the conversation interface include answer, chatTitle, fastAnswer, toolCall, toolParams, toolResponse, flowNodeStatus, flowResponses, updateVariables, interactive and error. A record that appears in a list does not by itself establish that a downstream business action was authorized, and an interactive form collects values rather than performing business verification, approval, database writes or external synchronization.
For a plugin-type application, the interface defaults to detail mode, chatId is not required because the plugin runs only one round, messages are not required, variables carry the plugin input, and pluginData carries the plugin output. These plugin conditions belong to plugin calls and do not change the requirements for ordinary conversation calls.
Configuration and implementation checks
| Check item | Setting or action | Relation to the sample |
|---|---|---|
| appId and chatId | Pass the target application and session identifiers in the request | Locates sample A1 and C9 |
| detail | Set to true when run details are needed | Reads responseData of D7 |
| stream | Choose according to the collection method; streaming is distinguished through event | Determines where the result is stored |
| source | Pass api in the session list request to obtain only API-created sessions | Judges whether C9 belongs to that source |
| loadCustomFeedbacks | Read custom feedback as needed in the conversation list request | Checks whether feedback is retained |
| pageSize and offset | For this exercise the starting values are 20 and 0; because the sample has only two records, they are compared with the list total | Used only for this paper check |
The pageSize and offset values are hypothetical starting points for this exercise, chosen because the sample conversation list is small, and they are compared against the total returned by the list. They are not documented defaults. The authProxy condition applies only to FastGPT versions at or above v4.15.0, and a proxied identity still needs permission for the target application and session.
Three common errors
- Treating the conversation records of session C9 as delivery spend details. The input is the title and totalRunningTime returned by the conversation list; the comparison object is the draft sentence's claim of "fully retained spend details"; the list fields do not contain spend details, so the claim is not supported.
- Treating retrieval or form collection as authorized execution. The input is the query field in the run details of D7; the comparison object is the authorization conclusion "can be used directly for budget adjustment approval"; run details do not constitute approval authorization, and the conclusion remains to be verified.
- Counting sessions from different entries together. The input is the session list result with source=api; the comparison object is page sessions or sessions from other sources; the sample covers only the API source, and the status of other sources is unknown.
How to verify the setup
- Input the session list request for sample A1 and C9, and compare the chatId and updateTime in the returned list. The locating condition is met only when C9 appears and the source is api.
- Input the run detail request for sample D7, and compare moduleType and query in responseData. The reading condition is met only when chatNode appears and query is "This week's Kuiche spend versus transaction difference"; if it does not appear, record the gap.
- Input the full draft sentence and compare its two claims of "fully retained spend details" and "can be used directly for budget adjustment approval" against the material. The material does not state the corresponding field or authorization, so the sentence is judged not supported, and the evidence gap is retained.
These are expected outcomes for a paper check, not results of an executed test. A relevance score is not a category, entity or permission filter, and retrieval does not perform authorization. Where a field is not documented, its value remains unknown.