Use a Full Callout Payload when Salesforce needs to call an external API and then do something useful with the response. That is the main difference between a Full Callout and an Outbound Webhook. A webhook is normally about sending an event and checking whether it succeeded. A Full Callout is for a fuller exchange: build the request, send it, model the response, and optionally write response values back into Salesforce.

If you are still choosing between Payload types, start with Choose a Payload type.

Use a Full Callout Payload when you need to:

The Stripe demo Payload creates a Checkout Session from a Salesforce Opportunity. It queries the Opportunity, builds the Stripe request, sends it to Stripe, and is ready to map values from the Stripe response back into Salesforce.

A Full Callout Payload has two main sides: Callout and Response.

The Callout side describes the request Payloads sends to the external API. It can include Dynamic Inputs, Data Queries, Body elements, Headers, Parameters, and Modifiers.

The Response side describes what Payloads expects to receive back. It can include a response Body model, response Headers, and Data Targets for writing response values into Salesforce.

The Full Callout layout keeps the outbound Callout configuration and inbound Response handling on the same Payload record.

Start with the main fields on the Payload record.

For most production callouts, Fail On Non 2xx is the right starting point. It keeps failed API responses visible in Job records instead of treating them as successful runs.

Dynamic Inputs are values supplied when the Payload runs.

Use them for values that change each time but are not stored directly on the Payload, such as a record Id passed from Flow, a session Id passed from another Payload, or a value selected by a user.

Once an input is referenced in the Payload configuration, Payloads shows it in the Dynamic Inputs tab. That gives admins a quick way to see what the Payload expects at runtime.

Data Queries fetch Salesforce data before the callout is built.

Use a Data Query when the API request needs values from Salesforce records. In the Stripe checkout example, the Payload queries an Opportunity, then uses fields from that Opportunity to build the checkout request.

Each query should have a clear purpose. Keep the record limit tight where possible, and make sure the filter matches the way the Payload will be run.

The Body tab defines the request body.

For JSON and XML, the Body is usually a tree of Elements. Each Element represents a value, object, array, or attribute in the outgoing request. For form URL encoded requests, the Elements represent the name/value pairs Payloads sends to the API.

Each Body Element needs a source. Common sources are:

The Stripe demo uses all of these patterns. Currency is transformed to Stripe's lower-case format, amount is transformed into minor units, and Opportunity fields are used for the checkout session.

Use Headers for HTTP headers that are part of the request, such as Content-Type, Idempotency-Key, or custom routing values.

Use Parameters for query string values. Payloads appends these to the endpoint URL when the request is sent.

Use Modifiers when part of the endpoint URL itself needs to be replaced at runtime.

For example, an endpoint such as /customers/CUSTOMER_ID can use a Modifier to replace CUSTOMER_ID with a Salesforce value or Dynamic Input.

Credentials are normally a better place for authentication headers. Keep authentication in the Credential where possible, and use Payload Headers for request-specific values.

The Stripe checkout example uses request headers for call-specific metadata, while authentication stays on the Credential.

Request parameters are appended to the endpoint URL when Payloads sends the callout.

The Response Body tab describes the values Payloads should understand from the API response.

You do not need to model every field returned by the external API. Model the fields your team actually needs to read, display, store, or use later.

Use Response Headers when the API returns important values in headers rather than the body, such as a request Id, rate-limit value, or pagination cursor.

The response body only models the values Payloads needs later, such as the checkout session id, URL, and payment status.

Data Targets write values from the response back into Salesforce.

Use them when the API returns data that Salesforce should keep, such as an external Id, status, URL, error code, or timestamp.

A Data Target defines the Salesforce object, operation, identifier, and field mappings.

Keep the mapping narrow: write the values that are needed for operations or reporting, not every value the API returns.

Before you run the Payload, check that:

After the first test run, open the Job record and compare the outbound request, response status, response body, and any target updates.