Configure asynchronous Inbound Payloads
Use an asynchronous Inbound Payload when the caller should receive a response before the remaining integration work runs. Queueable and Batchable place that work in a later transaction.
Use Immediate when the HTTP response must contain results produced by the full sequence.
Choose the mode when creating the Payload
Open the Integration and select New Payload.
Enter the Payload details and choose Inbound.
Select Immediate, Queueable or Batchable under Firing Mode.
Save the Payload and configure its HTTP Request, HTTP Response and processing Actions.
Firing Mode is fixed after creation in version 1.53. The Edit Payload modal displays it but does not let you change it. If the workflow needs a different mode, create a Payload with that mode and configure and test the replacement before switching callers.
Queueable uses background queueable execution. Inbound Batchable processing depends on the configured Payloads Batch Engine; confirm it is running. This differs from the dedicated CSV Batchable runtime.
Choose the Inbound firing mode at creation; it is fixed afterwards.
Configure the early response
An asynchronous Inbound sequence begins with HTTP Request followed immediately by HTTP Response. Add processing Actions after that response, at the permitted insertion points.
Define the request Body, Headers and Parameters needed by both the early response and later processing. In HTTP Response, map only values already available at that point, such as incoming request data or static acknowledgement text.
Do not map a later Target ID, Query result or Flow output into the early response. That processing has not happened when the caller receives the reply.
A successful asynchronous endpoint request returns HTTP 200 with the configured response. It does not automatically become an HTTP 202 response or a new Job-ID polling contract. Agree the acknowledgement format with the calling system.
The acknowledgement uses incoming request data and static text. The child lookup runs in a later transaction.
Example: acknowledge a product lookup
Create a Queueable Inbound Payload with a String request field productId. Configure the early response with a String status set to the static value accepted, and a String productId mapped from HTTP Request → Body · productId. Add the child lookup from Call another Payload as an Action after HTTP Response.
A request containing {"productId":"1"} receives HTTP 200 with:
{"status":"accepted","productId":"1"}The response deliberately contains no product name: that value is produced by the later Action. In the verified Queueable run, the Job subsequently completed and the child Action published the product name.
A request for a missing product also received the configured HTTP 200 acknowledgement. The subsequent child call returned HTTP 404 and the Job became Failed. Its HTTP Response Action still showed the original successful acknowledgement.
Check the final Job outcome even when HTTP Response completed successfully.
Monitor the background work
Send a controlled request through the configured Endpoint, then open the resulting Job. Compare the early response with the later Action results.
An acknowledgement confirms the request was accepted for background processing; it does not establish that every later Action succeeded. Monitor failed and queued Jobs and provide an operational route for resolving them.
If using Batchable, also check the Batch Engine and native Apex execution when work remains queued. Salesforce scheduling can delay execution.
What to check
Test the response before relying on it as a caller contract. Test a successful run and a later processing failure, and confirm that your monitoring catches the failure even though the caller already received its response.