Use form URL encoded content when an API expects fields in application/x-www-form-urlencoded format.

This is common for token endpoints, older REST APIs, and some payment APIs. The wire format is different from JSON, but the Payloads setup still uses Elements so the structure is visible and each value can be mapped, reviewed, and tested.

That is useful because form URL encoded requests can become hard to read once they include bracketed paths, repeated values, or arrays. Modelling them as Elements gives you a clearer place to check the contract before you run the Payload.

Set the relevant Payload content type to Form URL Encoded.

Use Outbound Content Type when Payloads sends the form URL encoded body. Use Inbound Content Type when Payloads receives a form URL encoded body.

The content type controls how Payloads serialises outbound values and parses inbound values. Once this is set, the body can be built in the same Payload UI used for other content models.

The content type is configured on the Payload, while the individual body values are still modelled as Elements.

Create Body Elements for each value the API expects.

For a simple token request, that might be fields such as grant_type, client_id, and refresh_token. For a more complex API, the body can include bracketed paths or array-style values depending on the external API's convention.

Use the API documentation as the source of truth for field names. In form URL encoded bodies, a small difference in a bracket path can change how the receiving API interprets the value.

The body is still built from Elements, even though the runtime serialises it as form URL encoded content.

If the API expects repeated values, model the repeated part as an array.

In the Stripe checkout example, line_items is a repeated structure. The array is mapped from the queried OpportunityLineItems child records so each line item in Salesforce becomes one entry in the outbound body.

Do not fake arrays by creating unrelated fields with hard-coded indexes unless the API truly requires fixed positions. Use an array Element when the number of entries depends on runtime data. That keeps the configuration aligned with the way the Payload will actually run.

Map each leaf Element from the right source.

Use static values for constants such as mode=payment. Use Data Query fields when the value should come from Salesforce. Use Dynamic Inputs when the caller supplies the value at runtime. Use Transformations when the API expects a different format, such as lower-case currency codes or amounts in minor units.

Try to keep the mapping as close as possible to the reason the value exists. A constant should be static. A record value should come from a Data Query. A value supplied by Flow or Apex should be a Dynamic Input.

After testing, open the Job and review the outbound or inbound body.

The Job is the fastest way to confirm whether Payloads serialised the field names, bracket paths, values, and repeated entries in the shape the API expects. If the external API rejects the request, compare the Job body with the API documentation before changing several mappings at once.

For more detail on outbound body mapping, see Map outbound request bodies.

Before testing, check that:

If the external API rejects the request, compare the Job body with the API documentation field by field.