Outbound Payloads often need more than a request body.

Many APIs expect values in the HTTP headers, query string, or URL path as well. Payloads separates those concerns so you can review each part of the outbound request without digging through code or manually assembling a URL.

Use Headers for HTTP headers, Parameters for query string values, and Modifiers when part of the endpoint URL needs to be replaced at runtime.

Use Headers for values the receiving API expects in the HTTP header set.

Common examples include idempotency keys, correlation ids, tenant identifiers, content negotiation, or request metadata. These are values that travel with the request but are not part of the body.

Authentication should usually live on the Credential, not as a Payload-level Header. Use Payload Headers for values that belong to this request rather than to the authentication method. That keeps authentication reusable and stops request-specific configuration from being mixed with credential setup.

Headers are useful for request-specific metadata such as idempotency or trace values.

Use Parameters for query string values.

Payloads appends Parameters to the endpoint URL when it sends the request. For example, a Parameter named expand with the value customer becomes part of the query string.

Parameters are a good fit for filters, expansion options, version flags, or other values the API expects after the ? in the URL. They should not be used to replace a path segment inside the endpoint itself.

Parameters become query string values on the outbound request URL.

Use Modifiers when the endpoint URL contains a placeholder that should be replaced at runtime.

For example, an endpoint such as:

can use a Modifier to replace CUSTOMER_ID with a Salesforce field, Dynamic Input, or other available value.

Modifiers are different from Parameters. A Parameter is appended to the query string. A Modifier changes the URL path or another placeholder in the endpoint value.

Use Modifiers when the endpoint itself contains a placeholder that should be replaced before the request is sent.

Headers, Parameters, and Modifiers use the same general mapping approach as Body Elements.

Depending on the Payload configuration, the value can come from:

Use static values for constants only. If the value changes per run, map it from runtime data instead. This makes the Job easier to explain later because the runtime value can be traced back to a clear source.

Attach a Transformation when the source value is correct but the outbound API expects a different format.

For example, a Salesforce value might need to be lower case, converted into a different date format, or combined with another value before it is sent.

Keep transformation names specific enough that another admin can understand why the value changes. A name such as Format Fulfilment Date For ERP is more useful than Date Formula when someone is troubleshooting a failed request six months later.

After a test run, open the Job and review the outbound values Payloads produced:

The Job shows the values Payloads built at runtime, which is more useful than reviewing configuration alone. If the API rejected the request, compare these values with the API documentation and the raw response body before changing the Payload.

Before testing, check that:

If the external API returns a 400, 401, or 403, compare the Job's outbound values with the API documentation and the Credential setup.