Pinduoduo seller campaigns: HTTP integrations for procurement

Review HTTP integrations for procurement in Pinduoduo seller campaigns. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

Low-price campaign operations on Pinduoduo revolve around campaign registration forms, product cost calculation sheets, after-sales refund documents, and platform messages. These materials draw on the merchant backend, campaign resource-slot data, ERP inventory, and logistics delivery records, and they update daily or per campaign. For procurement and supplier records, the HTTP integration step must separately verify supplier identity, material number, registration quantity, and procurement status. When a field is missing, the correct action is to record the gap rather than presume a specific response or error.

The feature under review is the HTTP module in FastGPT v4.17.2. That module can be added repeatedly, configured manually, and triggered to send an HTTP request to a corresponding address, operating in a manner similar to Postman and ApiFox. Params are path request parameters, used mostly in GET requests. Body is the request body, used mostly in POST and PUT requests. Headers carry special information. All three data categories can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables, and preceding node outputs. System variables include appId, chatId, responseChatItemId, variables, cTime, and histories, the last of which defaults to a maximum of 10 entries and cannot have its length modified. Return values are extracted through JSON path syntax, and when the output type is set to string, the value of the corresponding key is converted into a JSON string.

chatId and responseChatItemId are conversation system variables and do not exist in test mode. The APIKey, appId, detail, and authProxy rules of the FastGPT chat API are verified separately under that API and cannot be used to infer the authentication contract of an external ERP.

Hypothetical paper exercise: On 10 March 2026, a Pinduoduo store's campaign operator compiles a supplier record whose source text reads: "Supplier A, material number A-100, campaign registration quantity 800 pieces, purchase order CG-0310-01, status is awaiting supplier confirmation." On the same day, an HTTP request to an external ERP is drafted with the body {"supplier":"Supplier A","sku":"A-100","qty":"{{campaign quantity}}","po":"CG-0310-01"}, where the variable "campaign quantity" is not provided in the current node output. The question to decide is whether this request has an executable field basis and an authorization state.

Constraints at the HTTP integrations step

The HTTP module sends a request to a corresponding address and can be added repeatedly, configured manually, and triggered to execute. Params cover path request parameters and appear mostly in GET requests. Body covers the request body and appears mostly in POST and PUT requests, taking effect only under specific request types. Headers carry special information. Variables can be referenced in all three data categories and in the URL. The variable sources are global variables, system variables, and preceding node outputs.

The system variables available for reference are appId, chatId, responseChatItemId, variables, cTime, and histories. The histories variable defaults to a maximum of 10 entries and its length cannot be modified. chatId and responseChatItemId do not exist in test mode, so an empty value for them during testing is not a business fault.

Return values are not the interface's own return values. They define how to parse the interface response, extracting values through JSON path syntax. After FastGPT v4.6.8, output formatting was added, mainly converting JSON into strings. When the output type is set to string, the value of the corresponding HTTP key is converted into a JSON string and output. This means the HTTP output can be passed to text processing, concatenated with appropriate prompts, and then fed into an AI conversation.

For the procurement task, the constraint is that the HTTP module reaches an external address, but reaching that address does not establish authorization to act. Retrieval or form collection does not constitute authorization. The FastGPT chat API documents its own APIKey, appId, detail, and authProxy rules; those rules govern that API and cannot be extended to an external ERP's authentication contract. An unsigned termination is not a completed termination, and a pending request is not an approval.

Configuration and implementation checks

Configuration itemHypothetical starting point for this exerciseReason and comparison method
Request address and methodFill in according to the external ERP interface document; the address can reference a variableCompare field by field with the external interface contract to confirm the path and method match
Params and HeadersAuthentication mechanism and fields await confirmation from the real ERP contractCredentials are supplied through secure configuration; no actual secret is written into the sample
Body structureThe listed supplier, sku, qty, and po are proposed key names for the exerciseActual field names and types await contract confirmation; verify variable binding item by item
Variable referenceReference only global variables, system variables, and preceding node outputsCheck whether "campaign quantity" appears in the available variable list
Return value extractionConfigure key and output type according to JSON path syntaxCompare extraction results against an interface response example; string output type converts to a JSON string
Debug identity fieldschatId and responseChatItemId do not exist in test modeAn empty value in test mode is not recorded as a business fault

Three common errors

  1. Treating an unbound variable as a known interface fault. Check the drafted Body against the available variable list. "Campaign quantity" is currently absent, so record the binding gap first. The {{campaign quantity}} syntax remains valid; without execution, no assertion can be made that an empty value, the literal text, or a particular error will be sent.
  2. Treating a pending status as authorized execution. The sample source text carries the status "awaiting supplier confirmation." The input is the source status field and the drafted request; the comparison is between the status value and the execution condition; the observable result is that the status does not record a completed confirmation, so the request lacks an executable basis.
  3. Treating a retrieval result as a permission basis. The HTTP module can connect to external data sources, but retrieval or form collection does not constitute authorization. The input is the request-initiation action and the authorization status field; the comparison is whether an explicit authorization record exists; the observable result is that with no authorization record, the request remains in a to-be-verified state.

How to verify the setup

  1. Input the original drafted JSON and the variable list, and check the binding of "campaign quantity" and the type of qty. The source value of 800 pieces is a campaign registration quantity and does not automatically equal a confirmed procurement quantity. The variable and the real ERP contract are not provided, so supply the basis first. Pre-request validation and interception require separate implementation; the HTTP node cannot be claimed to block sending automatically.
  2. Against the sample source status "awaiting supplier confirmation," the input is the source status field and the proposed action; the comparison is between the status value and the execution condition; when the status does not record a completed confirmation, the judgment is unsupported, and the evidence gap is preserved.
  3. After a real ERP response sample is obtained, check whether the JSON path exists, what value it extracts, and whether the output type matches the downstream convention. No response sample exists now, so the parsing result awaits verification; the configured key cannot be used to presume the interface has returned that field.

These judgments take the paper sample as their object. No interface was actually called, and no deployment, approval, or refund business action occurred. An empty result can be carried forward by checking downstream design against a clearly defined paper input; it cannot be claimed that a fictional-rule retrieval necessarily returns an empty array. Libraries across different vector models cannot be jointly associated; verify the identifier first and exclude those that do not match, rather than running a cross-model retrieval to compare missed recalls.