Create your first Payload
A Payload is one runnable integration step.
It might send a request from Salesforce, receive a request from another system, handle an inbound email, or maintain a credential flow.
Create the Integration first, then create the Payload inside that Integration. That keeps the Payload grouped with the right Credentials, Transformations, Jobs, and related configuration.
If you have not created an Integration yet, start with Create your first Integration.
Before you start
Open the Integration that this Payload belongs to.
Decide what one job this Payload should perform.
Keep the external API documentation nearby if the Payload calls or receives data from an API.
Decide whether the Payload is sending data out, receiving data in, handling email, or supporting credential refresh.
Do not try to make one Payload handle every API call for a system. A useful Payload has a clear job, such as Create Checkout Session, Get Customer, Receive Order Event, or Send Fulfilment Update.
Open the Integration
Open the Payloads app, select the Integrations tab, then open the Integration that should own the Payload.
The Integration detail page contains the Payloads panel. This is where you create and review the Payloads that belong to that external system or workflow.
Create the Payload
In the Payloads panel, select New Payload.
Enter a clear Name.
Check the generated API Name.
Add a Subtitle.
Add a Description.
Choose a Payload type.
Select Save.
The New Payload modal captures the Payload name, generated API Name, short summary, operating notes, and starting type.
The Name should describe the specific action the Payload performs. Use names like Create Checkout Session, Get Customer, Receive Order Event, or Send Fulfilment Update.
The API Name is generated from the Integration name and Payload name. Treat it as a stable identifier once other configuration or automation starts using the Payload.
Use the Subtitle for a short summary of what the Payload does.
Use the Description for operating context: the external API endpoint, API documentation links, request and response notes, mapping behaviour, ownership notes, or anything a future admin should know before changing it.
Choose the Payload type
The Payload type controls which sections appear on the Payload page and how Payloads treats the work at runtime.
For a detailed comparison, see Choose a Payload type.
Choose the type that matches the direction and trigger:
Outbound sends a request from Salesforce to another system.
Inbound gives another system a way to send a request into Salesforce.
Email Handler receives inbound email and processes the email content in Salesforce.
Credential Payload supports credential-related callouts, such as maintaining an access token.
If you are not sure which type to choose, start from the direction of the data. If Salesforce starts the request, start with Outbound. If another system starts the request, start with Inbound. If the trigger is an email message, choose Email Handler.
Most users do not create Credential Payloads manually. They are normally created as part of a credential setup that needs a refresh flow.
Complete the runtime fields
After saving, Payloads opens the new Payload.
For Outbound, Inbound, and Credential Payloads, Payloads opens the Edit Payload modal straight away because those types need extra runtime settings before they can run.
The Edit Payload modal shows the runtime fields that apply to the selected Payload type, including callout settings, response handling, and Job cleanup.
At minimum, check the fields that match the Payload type you selected:
Endpoint and Method, when the Payload makes an outbound call.
Timeout, so a slow external API does not leave the Job waiting indefinitely.
Credential, when the external API requires authentication.
Outbound Content Type, which is the format Payloads sends or returns.
Inbound Content Type, which is the format Payloads expects to receive.
Response Failure Policy, which tells Payloads how to decide whether a response should fail the Job.
Job Cleanup, which controls how long Jobs for this Payload should be retained.
Save the Payload once the required fields are complete.
Review the Payload page
After the runtime fields are saved, review the Payload page.
The Payload detail page shows the runtime actions, key fields, and custom configuration sections that belong to the selected Payload type.
The header gives you the main actions:
Edit changes the Payload identity, type, runtime fields, response policy, and Job cleanup settings.
Export downloads the Payload configuration for backup or migration.
Run Payload starts the Payload manually when the Payload type supports manual execution.
Jobs opens recent runtime activity for this Payload.
The rest of the page changes based on the Payload type. For an Outbound Payload, the main sections are Request and Response. For an Inbound Payload, the Request section represents what the external system sends to Payloads, and the Response section represents what Payloads sends back.
What to check
After creating the Payload, check that:
the Payload belongs to the correct Integration
the Payload name describes one clear action
the API Name is readable and stable
the Payload type matches the direction and purpose of the integration step
the required runtime fields are complete
the right configuration sections appear on the Payload page
the Run Payload button is available only when manual execution makes sense for the Payload type
the Jobs action opens the runtime activity for this Payload
If Payloads shows Payload name already in use, choose a more specific Name and save again.
Next step
Configure the Payload details that match the type you selected.
For an Outbound Payload, that usually means adding the request body, headers, parameters, modifiers, data queries, and any Credentials or Transformations it needs. For an Inbound Payload, it usually means configuring the incoming request structure, response structure, endpoint, data targets, and target fields.