Return Salesforce data through an inbound Endpoint
Use this recipe when another system needs to call Salesforce and receive a structured response from Payloads.
This pattern is useful for controlled lookup-style APIs, status checks, fulfilment data, entitlement checks, or any case where the external system should receive a response built from Salesforce data without a developer writing a custom Apex REST service.
For the detailed Payload type article, see Configure an Inbound Payload that returns Salesforce data.
What you are building
The finished setup has four parts.
A Salesforce Site exposes the public route.
An Endpoint record receives the external request.
Data Queries read the Salesforce data Payloads should return.
Response body Elements map query fields into the outbound response.
The caller starts the process. Payloads reads Salesforce and returns the response.
Create the Payload
Create an Inbound Payload that returns Salesforce data.
Set the expected inbound headers and parameters if the caller needs to provide lookup values. These values can be used by Data Queries to find the right Salesforce records.
Do not use Dynamic Inputs for this Payload type. The runtime values come from the inbound request: headers, parameters, and body values.
Inbound request values are available to the Payload when the external system calls the Endpoint.
Query the Salesforce data
Create Data Queries for the records the response should include.
Use filters that are driven by inbound request values where possible. For example, a URL parameter can identify the customer, order, or reference number the caller is asking about.
Keep query limits intentional. A lookup-style endpoint should usually return one clear result or a bounded list, not an accidental dump of records.
Data Queries decide which Salesforce records are available when Payloads builds the response.
For query setup, see Configure Data Queries.
Build the response body
Model the response body to match what the external system expects.
Map response Elements to Data Query fields, static values, or transformed values. Use objects and arrays where the response structure needs nesting or repeated records.
If the response includes an array, make sure the array maps to a source query or child relationship that can produce multiple records. Elements inside that array can then use fields from the current array record.
The response model should be shaped for the caller, not for how the Salesforce records happen to be stored.
For response mapping concepts, see Understand Elements and mapping.
Create the Endpoint
Create an Endpoint from the Payload, choose the Site and HTTP Method, then copy the generated URL.
Give the caller:
the Endpoint URL
the method
required headers
required parameters
example response body
expected success and failure statuses
For Site and Endpoint setup, see Set up inbound endpoints and Sites.
Test the response
Call the Endpoint with realistic request values.
Open the Job and check:
inbound headers and parameters contain what the caller sent
Data Queries returned the expected records
the response body contains the expected shape and values
response status and status code are correct
no unexpected Salesforce fields are exposed
If the Job exists but the response is wrong, fix the query filters or response body mappings. If no Job exists, check the Site, URL, method, Endpoint Name, and guest user permissions.
Production checks
Before production use, confirm the Endpoint only exposes the data the external system is allowed to receive.
Inbound read endpoints are easy to underestimate because they do not write Salesforce records. They still expose Salesforce data, so review Site Guest User access, query filters, response fields, and retention of Jobs that capture request and response data.
For the broader checklist, see Secure Payloads for production.