Elements are how Payloads models API content.

An Element can represent a body field, a nested object, an array item, a header, a URL parameter, or a URL modifier. The Element tells Payloads where a value belongs and where that value should come from when the Payload runs.

For the broader runtime picture, see Understand Payload data flow.

Every Element answers three practical questions.

For body Elements, the location is usually a path such as $.line_items.price_data.unit_amount. For headers and parameters, the location is the header or parameter name. For modifiers, the location is the token in the endpoint URL that should be replaced.

The Element tree mirrors the structure Payloads will build when it sends the request.

The Element structure describes the shape of the content. The Element source describes the value.

That separation is important. A request body can keep the same structure while different Elements use different sources:

In the Stripe checkout example, line_items is an Array Element backed by the queried OpportunityLineItems child records. line_items.price_data.unit_amount is part of the request structure, but the runtime value comes from the current OpportunityLineItem's Unit Price. Payloads shows that directly in the Body table, so users can review the API field and its Salesforce source from the same screen.

The Body table shows the mapping source beside each Element, including child-record fields such as OpportunityLineItem Unit Price.

Nested API content is built from parent and child Elements.

The root Element usually represents $. Payloads creates the root as an Object by default because most API bodies start as an object. If the external API expects a top-level array, change the root Element to Array and build the rest of the structure underneath it.

Child Elements under the root become top-level fields. Elements under another Element become nested fields.

Array Elements create repeated structure. A line_items Array can repeat once for every record returned by a Data Query or child relationship. Fields inside that Array can use the current array record as their source, while fields outside the Array use single-record values from the wider Payload context.

The parent-child tree is easier to maintain than hand-written JSON because each value remains visible and editable on its own row.

Outbound Elements build what Payloads sends.

Inbound Elements model what Payloads expects to receive or parse. You do not need to model every field in an API response or inbound request. Model the values your integration uses for field mappings, response output, transformations, troubleshooting, or later Payload runs.

The response model only includes fields the integration needs to read or store.

Use Dynamic Inputs when the value is not fixed on the Payload and should be supplied when the Payload runs.

In the fulfilment update demo, the Stripe session id is a Dynamic Input. The same Payload can be reused for different sessions because the session id is passed in at runtime.

Dynamic Inputs keep runtime values visible without hard-coding them into the Payload.

Before testing an Element mapping, check that:

After testing, open the Job and compare the configured Elements with the outbound or inbound data that was captured.