Choose a Payload type
The Payload type tells Payloads what kind of integration step the Payload represents.
It controls which configuration sections appear on the Payload record, which runtime behaviour is available, and what Payloads expects to do when the Payload runs.
Choose the type before you start building the detailed request, response, target, or email configuration. You can edit a Payload later, but changing the type after configuration has been added can make the record harder to understand and maintain.
If you are creating your first Payload, start with Create your first Payload.
Start with the direction
Most Payload type decisions start with one question: who starts the interaction?
If Salesforce starts the interaction, you are usually choosing Full Callout or Outbound Webhook.
If an external system starts the interaction, you are usually choosing API Push Into SF, API Pull From SF, or Email Service.
If the Payload exists to maintain authentication, it will usually be a Credential Payload created automatically for a Bearer Token Credential.
Full Callout
Use Full Callout when Salesforce sends a request to an external API and the response matters inside Salesforce.
This type is a good fit when you need to:
send Salesforce data to an external API
receive a response from that API
read values from the response
write response data back into Salesforce
keep the request and response configuration together
Common examples include creating a checkout session, creating a customer in an external system, fetching a customer profile, or sending an order and saving the returned external ID.
Full Callout Payloads usually need an Endpoint, Method, Credential, outbound content type, inbound content type, request configuration, and response handling.
For setup steps, see Configure a Full Callout Payload.
Outbound Webhook
Use Outbound Webhook when Salesforce sends a request to another system and the main outcome is whether that request succeeded.
This type is a good fit when you need to:
notify another system that something happened in Salesforce
send a compact event-style request
fail or pass the Job based on the response status
avoid building a detailed response mapping when the response body is not important
Common examples include sending fulfilment updates, notifying an external case system, or pushing simple status changes to another platform.
Outbound Webhook Payloads usually need an Endpoint, Method, Credential, outbound content type, and response failure policy.
For setup steps, see Configure an Outbound Webhook Payload.
API Push Into SF
Use API Push Into SF when an external system sends data into Salesforce and Payloads should write that data to Salesforce records.
This type is a good fit when you need to:
receive webhook-style requests from an external system
parse the inbound body, headers, or parameters
map inbound values to Salesforce records
create or update Salesforce records from the request
keep inbound mapping visible inside Salesforce
Common examples include receiving payment events, order updates, shipment updates, customer profile changes, or support ticket events.
API Push Into SF Payloads usually need inbound body, header, parameter, target, and target field configuration.
For setup steps, see Configure an API Push Into Salesforce Payload.
API Pull From SF
Use API Pull From SF when an external system needs to request Salesforce data through a Payloads endpoint.
This type is a good fit when you need to:
expose selected Salesforce data to another system
control the query and response shape from inside Payloads
let another system pull data when it needs it
return a structured response without building a custom Apex API
Common examples include exposing payment status, returning account details, returning available products, or providing order status to an external portal.
API Pull From SF Payloads usually need query and outbound response configuration.
For setup steps, see Configure an API Pull From Salesforce Payload.
Email Service
Use Email Service when the inbound event is an email rather than an HTTP request.
This type is a good fit when you need to:
receive emails into Salesforce
read the email subject, sender, body, or attachments
map email content into Salesforce records
support systems that can send email but cannot call an API
Common examples include processing billing emails, supplier notifications, support updates, or mailbox-based operational messages.
Email Service Payloads usually need email service configuration and inbound target mapping.
For setup steps, see Configure an Email Service Payload.
Credential Payload
Use Credential Payload when the Payload exists to maintain authentication for another Payload.
You should not normally create this type manually. Payloads creates Credential Payloads automatically when you create a Bearer Token Credential.
This type is a good fit when you need to:
refresh an access token
call an authentication endpoint
validate that a Credential still works
keep authentication maintenance separate from business Payloads
Common examples include OAuth token refresh flows.
Credential Payloads usually need an Endpoint, Method, outbound content type, inbound content type, and Credential-related configuration.
For setup steps, see Configure a Credential Payload.
Quick choice guide
Choose Full Callout when Salesforce sends a request and needs the response.
Choose Outbound Webhook when Salesforce sends a request and mainly cares whether it succeeded.
Choose API Push Into SF when another system sends data into Salesforce.
Choose API Pull From SF when another system requests Salesforce data.
Choose Email Service when the inbound message is an email.
Use the generated Credential Payload when the Payload supports authentication rather than a business process.
What to check
Before you save the Payload, check that:
the type matches who starts the interaction
the type matches whether data is moving into Salesforce, out of Salesforce, or both
the Payload name describes one clear action
the Integration has the Credentials and Transformations the Payload may need
the required sections appear after saving
If the visible sections do not match what you expected, check the Payload type first. The type is what determines which configuration areas Payloads shows.
