Use a Salesforce Site when an external system needs a public entry point for an Inbound Payload. Authenticated API clients can also call the Apex REST route through the org domain; a successful authenticated test does not verify Site guest access.

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 an Inbound Payload and choose its Firing Mode before saving. Use Immediate when the caller needs processing results in the response. Queueable and Batchable return an early acknowledgement; their later processing result is recorded on the Job.

In Actions, select HTTP Request. Edit Request Settings to choose the incoming Content Type, then define the Body, Headers and Parameters needed by your mappings. Add Query, Target, Flow or eligible child Payload Actions in the permitted positions.

Select HTTP Response to define the outgoing Content Type and response body. For asynchronous Inbound, the response cannot use outputs from Actions that run after the acknowledgement.

See Configure asynchronous Inbound Payloads.

Select HTTP Request and create an Endpoint from its Endpoints section.

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. Check its Status and Error Message, select HTTP Request to inspect the received body, headers and parameters, and select HTTP Response to inspect the response. Review each Query, Target, Flow or child Payload Action that processed the request.

If no Job is created, check the Site URL, Site status, endpoint path and guest user access. Test through the public Site URL when verifying guest access; an authenticated org-domain request uses a different user context.

Before going live, check that: