What the documents look like
Multi-warehouse allocation decides which warehouse ships an order, and it happens during order routing rather than at courier handover. The working data comes from WMS, OMS, ERP inventory and platform inventory interfaces. Daily documents include allocation rules, inventory synchronization tables, transfer orders and stockout alerts. Update frequency is daily or hourly. This page concerns what the conversation logs and audit step must handle: the session records, run details and feedback fields left by these business steps inside after-sales question answering.
A returned log only shows that the interface returned content. Reconciliation, retention and compliance requirements belong to a complete business solution implemented elsewhere. The presence of a log does not complete a compliance audit.
For this task, the relevant identity is chatId. Compare the target conversation against the business record by chatId, and do not merge sessions from different entry points into one count. When run details are needed, set detail according to the official contract and inspect the module status and complete results inside responseData. Compare the log against the fields the interface actually returned; business data that was not returned cannot be assumed to be fully retained. Identity fields in test mode may differ, so check the input, the history and the returned content separately.
Constraints at the conversation logs step
The chat/completions interface uses APIKey authentication. 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 unnecessary. 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; if a 404 appears, add v1 and retry. To proxy a team member identity through authProxy, the team owner must enable authProxy when creating or editing that key, and the proxied identity still needs permission on the target application and conversation. This applies only to FastGPT >= v4.15.0.
Passed-in model and temperature fields have no effect; orchestration decides these and API parameters do not change them. The actual consumed Token value is not returned. If it is needed, set detail=true and manually calculate the tokens values inside responseData.
When chatId is absent, FastGPT context is not used and the passed messages build the context entirely. When chatId is a non-empty string, the conversation is retrieved automatically from the FastGPT database and the last item in the messages array is used as the user question, with the remaining messages ignored. The chatId must be unique and shorter than 250 characters, and it can be the dialog ID of an external system. When responseChatItemId is passed, it becomes the ID of this conversation's response message and FastGPT stores it in the database; it must be unique under the current chatId. The variables object replaces [key] inside module input fields.
Hypothetical paper exercise sample: on 10 March 2025 a supply chain planner submits a handover request whose text reads "On 10 March, warehouse A sellable stock is 120 units and warehouse B is 80 units; the allocation rule gives warehouse A higher priority than warehouse B; please confirm whether order 001 ships from warehouse A on 11 March." A draft sentence reads "Order 001 is confirmed to ship from warehouse A." The request is pending determination and does not constitute a shipment execution or an inventory deduction.
Configuration and implementation checks
| Configuration item | Hypothetical starting value for this exercise | How to check |
|---|---|---|
| chatId | chat-001 for the sample | Compare against the business record item by item to confirm one session |
| detail | true for the sample | Inspect whether responseData contains module status |
| responseChatItemId | resp-001 for the sample | Confirm uniqueness under the current chatId |
| source | api for the sample | Take only API-created sessions, not page sessions |
| loadCustomFeedbacks | true for the sample | Read the custom feedback fields |
| pageSize | 10 for the sample | Pair with offset to page through records |
These values are starting points for this paper exercise, not official defaults. The reason for choosing them is to keep the sample small enough to compare by hand. The comparison object is the official description of the corresponding field and the sample record on this page.
The interactive node response is a configuration display. When a workflow reaches an interactive node it returns directly. With stream=true the configuration is available from data.interactive in the interactive event; with stream=false it is available from the element containing the interactive field inside choices[].message.content. The interactive returned to the external caller contains 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. To continue, call the same interface again with a consistent chatId: for user selection, pass the single selected result in messages; for form input, serialize an object whose keys match the form keys and whose values are the user inputs, and pass it as the messages content.
Three common errors
- Merging sessions that have different chatId values into one count. Input two distinct chatId values, compare whether they identify the same session, and the observable result should be two separately listed sessions.
- Treating a detail=false response as if it contained run details. Input a request with detail=false, compare whether responseData is present, and the observable result should be that this field is absent.
- Treating the form configuration returned by an interactive node as already submitted. Input the interactive display configuration, compare whether it contains user input values, and the observable result should be that it contains only type and params.
How to verify the setup
- Input the hypothetical sample source text and the draft sentence, compare whether the draft sentence contains the completed wording "confirmed to ship from warehouse A," and the observable result should be pending verification rather than a determination of execution.
- Input chat-001 and a second chatId, compare the session identifiers returned by the two calls, and the observable result should be that each is independent and not merged into one count.
- Input a request with detail=true, compare the module fields inside responseData against what the interface actually returned, and the observable result should be that the fields correspond, with business data that was not returned recorded as missing.
A relevance score is not a category, entity or permission filter, and retrieval is not authorization. This page does not cover scheduled triggers, database writes or external synchronization; those require their own stated downstream implementation.