Inbound Payloads need a Salesforce Site before another system can call them.

The Site provides the public URL. Payloads provides the Apex REST endpoint and the Payload configuration that decides what happens when the request arrives.

There are two parts to get right: the public routing path and the Salesforce permissions behind it. If either part is wrong, the external system may not reach the Payload even though the Payload itself looks correctly configured.

For Endpoint record setup, see Configure Endpoints.

For production checks around Site guest users, Credentials, Endpoints, and Job data, see Secure Payloads for production.

Payloads exposes inbound requests through an Apex REST URL under the Site domain.

The URL follows this pattern:

The Endpoint record stores the Site, generated URL, method, path, and related Payload. This generated URL is the one you give to the external system.

Use a Salesforce Site that is intended for API traffic.

The Site should be active and reachable by the external system. Use a stable domain and path because external systems may store the URL in their own configuration.

If your org already uses Sites for other public endpoints, decide whether Payloads should share that Site or use a dedicated one. A dedicated Site can make permissions and operational ownership clearer, especially when Payloads endpoints are managed by a different team from other public Site features.

Assign the Payloads Site Guest User permission set to the Site Guest User.

The Site Guest User needs read access to the Payloads configuration required to route and run the inbound request.

If the inbound Payload writes to Salesforce records, also review object, field, validation, and sharing behaviour for the target records. Do not grant broad guest access to business data just to make an endpoint work. Keep the guest user permissions as narrow as the integration allows.

For permission guidance, see Set up permissions and access.

Create or open the Inbound Payload.

Set the Inbound Content Type to match what the caller will send. Set the Outbound Content Type to match what Payloads should return.

Configure request Body Elements, Headers, Parameters, Data Targets, and Response Body Elements as needed. The Payload should model the values Payloads needs to use, not necessarily every field the external system sends.

Create an Endpoint from the Payload page.

Choose the Site, Endpoint Name, and Method.

Payloads builds the URL using the Site domain and Endpoint Name. Check the generated URL before giving it to the external system.

If you are testing connectivity, use Echo Mode temporarily. Turn Echo Mode off before using the Endpoint as a live integration endpoint.

The Endpoint modal is where the Site, generated URL, method, and request access settings come together.

Give the external system the details it needs to call the endpoint correctly:

Use demo-safe values in screenshots and documentation. For live integrations, share endpoint access values through your normal secure process rather than pasting them into tickets or articles.

Send a small, representative request from the external system or an API client.

Then open the Job in Payloads and review:

If no Job is created, check the Site URL, Site status, endpoint path, and guest user access. If a Job is created but fails, use the Job detail to review the parsed inbound body, headers, parameters, response, target output, and error message.

Before going live, check that: