Inbound Payloads read values from requests sent by another system.

Those values can come from the request body, HTTP headers, or URL parameters. Payloads can then use them in Data Targets, response bodies, Transformations, and Job troubleshooting.

The aim is not to model every byte the caller sends. The aim is to model the values Payloads needs to route, validate, map, save, return, or diagnose later.

For endpoint setup, see Configure Endpoints.

Use the inbound Body section for values sent in the request body.

Set the Inbound Content Type on the Payload first. Payloads supports JSON, XML, form URL encoded content, and inbound email content for the relevant Payload type.

Model only the inbound values Payloads needs to use. For a large webhook, that might be an event id, event type, external record id, status, amount, and a few nested line-item values. You do not need to reproduce the full external payload if most of it is irrelevant to the Salesforce action.

The inbound request structure defines the values Payloads can read when the external system calls the Endpoint.

Use inbound Headers for values sent as HTTP headers.

Headers are useful for trace ids, event types, source identifiers, version values, or other metadata the external system sends outside the body.

If a header is needed for endpoint access, configure it on the Endpoint secret settings. If a header is needed for mapping, response output, or troubleshooting, model it in the Payload's inbound Headers section. Keeping those two purposes separate makes the Endpoint easier to secure and the Payload easier to understand.

Model inbound headers when the Payload needs to map, return, or troubleshoot them.

Use inbound Parameters for values sent in the URL query string.

Parameters are useful for routing values, ids, filters, or setup checks where the caller sends data in the URL rather than the body.

If a parameter affects what Salesforce data should be returned or updated, model it explicitly. That way it appears in Jobs and can be used in mappings just like the values from the request body.

Inbound parameters become available to mappings in the same way as other inbound values.

After an inbound value is modelled, Data Target fields can use it.

For example, an inbound payment event might use a body value to find an Opportunity, a header value to store the external event type, and a parameter value to record which external tenant sent the request.

This is where inbound modelling becomes operationally important. If a value is not modelled, it may still exist in the raw request, but it will not be as easy to use in target mapping or troubleshooting.

For target setup, see Configure Data Targets.

Inbound values can also be used when Payloads returns a response.

For example, an Inbound Payload might return a request id, a mapped Salesforce record id, a status value, or a query result that depends on an inbound parameter. This is useful for APIs where the caller expects Payloads to acknowledge the request with structured data rather than only an HTTP status.

For read-style inbound setup, see Configure an Inbound Payload that returns Salesforce data.

Every run records the inbound body, headers, and parameters on the Job when they are present.

Use the Job to confirm whether the caller sent the value, whether Payloads parsed it, and whether the downstream mapping used it. If a mapped value is blank, check the Job before changing the Payload. The issue is often that the caller sent a different field name, header name, or parameter name than expected.

Before testing, check that:

If a mapped value is blank, check the Job's inbound body, headers, and parameters before changing the Data Target.