Use this pattern when another system needs to request Salesforce data through a Payloads endpoint.

The external system starts the interaction. Payloads receives the request, reads headers or parameters if needed, queries Salesforce, then builds the response.

If the external system is sending data that Salesforce should store, use Configure an Inbound Payload that writes to Salesforce instead.

Use this pattern when you need to:

The Stripe demo Payload lets an external system request payment status by session id. Payloads reads the request parameter, queries the matching Opportunity, and returns a small response.

An Inbound Payload has a Request side and a Response side.

For this pattern, the Request side usually models inbound Headers and Parameters. The caller supplies values that tell Payloads what Salesforce data to return.

The Response side contains Data Queries, Body, and Headers. Those sections decide what Salesforce data is fetched and how it is returned.

The Endpoint section connects the Payload to the URL another system calls.

An Inbound Payload can read values from the Request, run Data Queries, and build the Response from Salesforce data.

Start with the main fields on the Payload.

The outbound content type is especially important. It controls how Payloads serialises the response body you build.

Use Request Headers when the caller sends values Payloads needs to read.

Examples include tenant identifiers, source system names, correlation ids, or values used in query filters. Do not model every possible header. Model the headers that are meaningful to the Payload.

The API response demo captures caller metadata before Payloads builds the Salesforce-backed response.

Use Request Parameters for values that filter or identify the Salesforce data to return.

The Stripe demo uses a stripeSessionId parameter. That value is then used by the Data Query to find the relevant Opportunity.

Give parameters clear names, and keep them stable. External systems will depend on them once the endpoint is in use.

Data Queries are the centre of this pattern.

Each query defines the Salesforce object, filter, and record limit Payloads uses before building the response. The filter can use request parameters, static values, or other supported filter inputs.

Keep queries intentionally small. This pattern works best when the endpoint returns a focused response for a specific use case, not a broad Salesforce data export.

The Data Query uses the inbound request value to find the Salesforce record that should drive the response.

The Response Body tab defines the content returned to the caller.

Build Elements for the fields the external system needs. Each Element can use a value from a Data Query, a Static Value, or a Transformation.

Keep the response shape stable once the external system starts using it. If you need a materially different response later, consider a new Payload or endpoint version.

Use Response Headers when the caller expects metadata outside the body.

Common examples include content type, cache hints, correlation ids, or custom status headers. Keep these aligned with the external system's API contract.

The Endpoint section defines the URL and method exposed by Payloads.

GET is often the right method for read-style APIs, but the method should follow the contract agreed with the external system.

If you need separate read behaviours, create separate Payloads and endpoints. That keeps each API easier to document, secure, and troubleshoot.

Before you test the endpoint, check that:

After a test call, open the Job record and confirm the inbound parameters, query results, response body, and response status.