Use this pattern when another system sends data to Payloads and Salesforce needs to store or update records from that request.

In Payloads, this is configured as an Inbound Payload. The external system calls a Payloads endpoint, Payloads parses the request, and Data Targets decide what happens to the inbound values.

For a broader comparison with the other Payload types, see Choose a Payload type.

Use this pattern when you need to:

The Stripe demo Payload receives a payment event and updates the related Opportunity from values in the incoming event body.

An Inbound Payload starts with the Request side.

The Request section models the inbound Body, Headers, Parameters, and Data Targets. Data Targets are the important part for this pattern: they decide which Salesforce records Payloads creates or updates.

The Response section defines what Payloads sends back to the caller after processing the request. It can include a response Body, Headers, and Data Queries when needed.

The Endpoint section connects the Payload to the API URL another system will call.

An Inbound Payload starts with the inbound Request, then shows how Payloads responds after writing data into Salesforce.

Start with the main fields on the Payload.

Choose the inbound content type carefully. It controls how Payloads parses the request Body and how Body Elements should be modelled.

The Request Body tab describes the incoming payload.

Create Elements for the values you need to read from the request. You do not need to model the full request body. Model the fields used for field mappings, decisions, transformations, or troubleshooting.

In the Stripe demo, the Payload models values such as event id, event type, checkout session id, payment status, and Salesforce Opportunity id.

Use Transformations where the external value is not the value Salesforce should store directly. For example, an event type can be transformed into a readable action label.

Use Request Headers when inbound header values matter to the integration.

Typical examples include tenant identifiers, source system names, request ids, or values used by downstream mappings. Only model headers your integration needs to read.

The demo models request headers that are useful for tracing the inbound event and mapping response values.

Use Request Parameters when the external system sends values in the query string.

Parameters are common for lightweight API calls where one or two values control what the Payload should do. If the value is part of the business event, it is usually clearer in the request Body. If it controls routing or filtering, a Parameter can be a better fit.

Request parameters are best for small routing or mode values, not for the main business event.

Data Targets turn inbound values into Salesforce record changes.

Each Data Target defines:

For updates, make sure the identifier maps to a value that Salesforce can use reliably. In the Stripe demo, the inbound event contains the Salesforce Opportunity id, so the target can update that Opportunity directly.

The Response section defines what the caller receives after Payloads handles the request.

A simple acknowledgement is often enough. For example, return an accepted status, a Salesforce record Id, or a message that confirms the event was processed.

Use response Headers only when the caller expects them, such as a correlation id or a content type value.

The Endpoint section defines how the external system reaches this Payload.

Create or review the Endpoint record, then give the external system the correct URL and method. Keep separate endpoints for separate integration behaviours. A payment event receiver and a customer update receiver should normally be different Payloads, not one overloaded endpoint.

Before you test the endpoint, check that:

After a test call, open the Job record and check the inbound body, parsed values, target results, and outbound response.