Introduction to Payloads
Payloads is a Salesforce-native tool for building and managing complex API integrations without writing a single line of code.
It gives you a way to configure the parts of an integration that would normally end up in custom Apex or external middleware: endpoints, authentication, request bodies, response handling, transformations, mappings, and run history.
The goal is simple: make API integrations visible and manageable inside Salesforce, so your team can build them, review them, change them, and support them from the Payloads app.
The Payloads home tab gives you a quick view of recent integration activity, failures, runtime trends, and cleanup status.
What Payloads does
Payloads breaks an integration into clear pieces that can be configured in Salesforce.
An Integration represents an external system or business process, such as order intake, fulfilment, billing, or customer updates.
A Payload represents one API interaction, such as sending an order update, receiving a webhook, or pulling customer data.
Credentials define how Salesforce authenticates with the external system.
Endpoints define where outbound requests are sent, or how inbound requests are received.
Transformations adjust values between the Salesforce format and the external API format.
Jobs show what happened each time a payload ran, including success, failure, request details, and response details.
That means the integration is not just a black box. You can open it in Salesforce and see how it is put together.
For example, this Stripe integration groups related Payloads, Credentials, and Transformations under one record.
What you can build without code
Payloads is designed for API integrations that need more structure than a basic point-to-point automation.
You can use it to:
Send Salesforce data to another platform.
Receive data from an external system and create or update Salesforce records.
Build webhook-style integrations.
Expose inbound endpoints for external systems to call.
Pull data from an API and map the response into Salesforce.
Transform values before they are sent, stored, or returned.
Keep a history of each integration run without building a separate logging framework.
For example, you might use Payloads to bring web orders into Salesforce, send case status updates to a customer portal, synchronise account data with a billing platform, or call a fulfilment API when an opportunity is closed won.
Those are the kinds of integrations that often start as custom code because the request shape, authentication, and response handling are too specific for a simple connector. Payloads gives you a configurable way to handle them inside Salesforce instead.
How Payloads fits into Salesforce
Payloads works alongside the Salesforce tools you already use. Your Salesforce data still lives in your normal objects. Flow can still drive a business process. Apex can still be used where the implementation genuinely needs code. Permissions, sharing, validation rules, and the object model still matter.
Payloads handles the integration layer around those pieces.
In practice, you usually:
Create an Integration for the external system or workflow.
Add one or more Payloads for the API calls you need.
Configure credentials, endpoints, request bodies, mappings, transformations, and response behaviour.
Run the payload directly, from Flow, from an inbound endpoint, from email processing, or as part of a larger Salesforce process.
Review Job records when you need to confirm what happened or troubleshoot a failure.
For a small integration, you might only need one Payload and one Credential. For a larger integration, you might group several Payloads under the same Integration, each handling a different API call.
Why use Payloads
The main reason to use Payloads is that integration configuration becomes visible and supportable.
When an integration fails, you need practical answers:
What ran?
What did Salesforce send?
What did the external system return?
Which credential, endpoint, mapping, or transformation was used?
Was this a Salesforce issue, an external API issue, or a configuration issue?
Payloads gives you a place to answer those questions without starting from debug logs or asking a developer to read through integration code.
It also makes integrations easier to change. If an endpoint moves, a credential changes, a field needs to be mapped differently, or the external API expects a different value, you can update the relevant configuration in Salesforce instead of rebuilding the whole integration.
You still need to understand the external API, authentication model, data shape, limits, error handling, and Salesforce security model. Payloads does not remove those design decisions. It gives you a no-code way to express and operate them.
Where to start
Start with the business process.
Decide what external system or workflow you are integrating with, then create one Integration for that area.
After that, add the Payloads, Credentials, Endpoints, Transformations, and mappings needed for each API interaction.
If you are new to Payloads, begin with one simple outbound call or one inbound request.
Once you can see how the configuration fits together and how Job history is captured, it is much easier to build a fuller integration.