What the documents look like
Creator commission settlement and deduction happen after a sale closes. The records to reconcile are valid promotion orders, refund commission deduction details, settlement statements, and invoices. The Selected Alliance backend, order after-sales data, the finance system, and creator contracts form the main data sources, and updates arrive weekly or monthly. Finance settlement staff, Selected Alliance operations, and creator business teams handle these documents together. Mistakes here produce creator disputes, incorrect finance entries, or stalled cooperation. This page covers only the HTTP integration and external system work in the order fulfillment and after-sales question stage, and it does not construct business functions that lack a documentary basis.
Two industry facts shape this integration step. First, commission settlement runs after the transaction, so the reconciliation target is the valid promotion order and the refund deduction, and any push to an external system carries a payment state that must match the source record. Second, the working documents change weekly or monthly, which means an integration request can reference a statement period that a later refund has already altered.
Constraints at the HTTP integrations step
The HTTP module sends a request to the corresponding address, and its operation is close to tools such as Postman and ApiFox. Params are path request parameters and are used more often in GET requests. Body is the request body and is used more often in POST/PUT requests. Headers are request headers and carry special information. All three data types can reference variables through {{}}, and the URL can also reference variables through {{}}. Variables come from global variables, system variables, and preceding node outputs. System variables include appId, chatId, responseChatItemId, variables, cTime, and histories. chatId and responseChatItemId do not exist in test mode. Return values are extracted with JSON path syntax, and when the output type is set to string, the value of the corresponding key is converted into a json string. The chat interface uses APIKey authentication, and when calling chat/completions it is recommended to pass body.appId in the request body; Authorization: Bearer <apiKey>-<appId> is also supported. Passed fields such as model and temperature have no effect. A plugin-type application does not need chatId or messages, uses variables to represent plugin inputs, and obtains plugin output from the element with moduleType=pluginOutput inside responseData. The interactive value returned by an interaction node contains only type and params, and internal runtime fields are not returned.
Hypothetical paper exercise sample: the source text of a settlement handover record awaiting reconciliation reads "Creator A, June 2025, 80 valid promotion orders, 12 refund commission deductions, settlement statement amount 6400 yuan, invoice issued but not paid." The proposed handover request reads "Push Creator A's June settlement statement to the finance system and mark it as paid." The source text states only that the invoice is issued and unpaid, while the proposed request asks to mark the record as paid, so the two differ in the value of the payment status field. The source text does not state the finance system interface address, the authentication method, or the push authorization. The request lacks an executable basis and is an item pending verification; it cannot be treated as authorized.
Configuration and implementation checks
The table below centers on the sample above and lists officially documented settings or implementation checks relevant to this function and primary task. The values are starting points for this hypothetical exercise, used for comparison against the source text or interface documentation, and they are not official defaults.
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Request address BaseUrl | The address given in the finance system interface documentation | The address can reference variables and must be compared word by word with the documented value |
| Request method | POST | Pushing a settlement statement is a write-type operation; compare with the method field in the documentation |
| Headers authentication | Authorization: Bearer placeholder credential | The credential is injected through secure configuration; compare with the authentication requirement in the interface documentation |
| Body fields | Statement number, amount, payment status | Compare field by field with the payment status value in the source text |
| Return value extraction key | data.result | Compare with the actual structure of the interface response JSON path |
| Debug identity fields | chatId and responseChatItemId left empty | These two variables do not exist in test mode; an empty debug value is not a business fault |
Three common errors
- Treating "mark as paid" in the proposed handover request as a fact already stated in the source text. The source text states only that the invoice is issued and unpaid, so the payment status value differs from the request requirement, and the request is an unsupported item pending verification.
- Applying the plugin output retrieval method to the chat interface. Plugin output requires finding the element with moduleType=pluginOutput inside responseData, while chat interface output is obtained through choices; the two retrieval locations differ.
- Treating passed model and temperature parameters as fields that can change orchestration behavior. These fields are determined by the orchestration and do not change according to API parameters, so a request parameter value cannot be used to infer the model that actually ran.
How to verify the setup
- Input the source text of the sample above together with the proposed handover request, and compare the payment status field. The source text says "unpaid" and the request says "mark as paid." The two values differ, so the item is judged pending verification, and the source text is not judged to negate payment.
- Input a POST request, compare the statement number and amount in the Body against the corresponding values in the source text, and at the same time compare the return value extraction key against the actual JSON structure of the interface response. Observe whether the extracted result matches the value at the corresponding path in the response.
- Input a plugin-type request, compare the pluginOutput of the element with moduleType=pluginOutput inside responseData against the expected plugin output, and observe whether the output is taken from that element. If the element does not exist in the response, record it as not observed and do not infer a cause of interface failure.
This page addresses only creator commission settlement and deduction, order fulfillment and after-sales questions, and HTTP integration with external systems. When operations hand over work, the authorization state of which materials, operations, and requests are involved must be clear, and retrieval or a form cannot be treated as authorized execution.