Use an Endpoint when an external system needs to call an Inbound Payload.

The Endpoint is the bridge between the public Salesforce Site URL and the Payload configuration inside Salesforce. It tells Payloads which Site should receive the request, which URL path and HTTP method are valid, and which Payload should run when the request arrives.

This matters because most inbound API problems are not caused by the body mapping at first. They usually start with routing: the caller used the wrong URL, the Site was not active, the method did not match, or the guest user could not read the configuration Payloads needs.

For the wider inbound setup, see Set up inbound endpoints and Sites.

Create an Endpoint for each inbound API behaviour you want to expose.

Use separate Endpoints when the external system is doing different work. For example, a payment event receiver, an order update receiver, and a status lookup should normally be separate Payloads and separate Endpoints. That gives each API action its own method, request model, response model, Data Targets, and Job history.

Avoid using one Endpoint as a catch-all. It may feel quicker during early testing, but focused Endpoints are easier to secure, easier to test, and much easier to troubleshoot when one caller starts behaving differently from another.

Open the Inbound Payload and find the Endpoint section.

Create or edit the Endpoint from the Payload page. Use the custom Endpoint modal rather than the standard Salesforce record page. The modal keeps the Site, generated URL, method, Echo Mode, and secret settings in one place, which is the way users actually reason about an inbound URL.

The Endpoint Name becomes the path segment Payloads uses in the generated URL. Use a short, stable name that describes the API action. Changing this later means the external system may need to update the URL it calls.

Create and edit Endpoints from the Payload page so the generated URL, method, and Site are visible together.

Select the Salesforce Site that should receive the request.

Payloads uses the selected Site to build the public URL. The URL follows this pattern:

The Site must be active, reachable by the external system, and configured with the correct Site Guest User permissions. If the Site is wrong, Payloads may be configured perfectly and still never receive a usable request.

Select the HTTP method the caller will use.

Payloads supports:

Choose the method that matches the external API contract. If the incoming request uses a different method, Payloads rejects the request and records a failed Job where possible.

Echo Mode is useful while setting up an inbound API.

When Echo Mode is enabled, Payloads can return a value from an inbound request parameter instead of running the Payload. This is a quick way to prove that the external system can reach the endpoint and that request parameters are arriving with the expected names.

Use Echo Mode for setup and diagnostics only. Once the caller can reach the URL reliably, turn Echo Mode off and test the real Payload behaviour.

Endpoint secrets let an Endpoint require a configured header or parameter before it accepts the request.

Use them for simple shared-value checks where the external system can send a known header or URL parameter. The Endpoint modal lets you choose whether the secret comes from a Header or Parameter and what should happen when the value is missing.

Treat these values as part of the endpoint contract. Do not put sensitive operational detail in article bodies or screenshots. Use demo-safe values when documenting or testing.

When a request reaches /services/apexrest/pylds/endpoint/..., Payloads follows a predictable routing path:

If the Endpoint cannot be found, the method is not allowed, or the Payload cannot be loaded, Payloads returns an error response and records the failure where it can. That is why the first Job created by a new Endpoint is so useful: it confirms that routing worked and shows exactly what Payloads received.

Before giving the URL to another system, check that:

After the first request, open the Job and review the inbound body, headers, parameters, response status, and error message.