Use this recipe when an external API expects one request that contains a parent record and a repeated list of child records.

A common example is a checkout or order request: the parent record contains the customer, currency, or reference values, while the child records become line items. In Salesforce terms, that might mean one Opportunity and multiple OpportunityLineItem records.

For the full mapping article, see Map outbound request bodies.

The finished setup has three layers.

The important idea is the index tree. Elements outside an array can only safely use fields from a single-record query. Elements inside an array can also use fields from the current record of that array.

Create a Data Query for the parent Salesforce record.

For example, query the Opportunity using a Dynamic Input such as $OPPORTUNITY_ID. Set the record limit to 1 when the request body should be built around one parent record.

Fields mapped outside arrays should usually come from this single-record query.

Create a query or child relationship for the repeated records.

For an Opportunity request, the child records might be OpportunityLineItem rows. These rows are what the external API should receive as line items, fulfilment items, invoice lines, or similar repeated entries.

For query setup, see Configure Data Queries.

In the outbound body, create an array Element where the external API expects the repeated list.

For a Stripe-style checkout request, that array is line_items[]. Map the array to the child record source. That source tells Payloads how many entries to create at runtime.

The array Element is the bridge between repeated Salesforce records and repeated API entries.

If the array is not mapped to a repeating source, Payloads does not know how many child entries to create.

Add child Elements inside the array for the fields the external API expects.

Because those Elements are inside the array, they can use fields from the current child record. For example, a unit amount Element can map to the current OpportunityLineItem amount, and a quantity Element can map to the current line item quantity.

Inside an array, Payloads can map fields from the current array record instead of only the parent query.

This is the part that usually makes the mapping click: the array establishes the current record context for its children.

Map parent-level fields outside the array.

Examples include customer email, currency, invoice reference, account id, description, or success and cancel URLs. These values normally come from the parent Data Query, a Dynamic Input, a static value, or a Transformation.

Do not map parent-only fields from the child array unless the external API really expects the value to repeat once per child row.

Run the Payload and open the Job.

The outbound body should show one parent request containing an array with one entry per child record.

The Job is the quickest way to confirm the array expanded correctly at runtime.

If the array is empty, check the child query and filter values. If every array entry repeats the same value, check whether the child Elements are mapped to the current array record or to a parent query.

The most common mistake is mapping child fields outside the array. Payloads then has no current child record, so it can only use values from a single-record context.

Another common mistake is creating an array Element but not mapping it to a repeating source. The request structure may look right in configuration, but the runtime has no source records to expand.

When debugging, check the Job in this order: Dynamic Inputs, Data Query output, array Element mapping, child Element field mappings, then the generated outbound body.