This reference summarises the main Payload configuration values.

Use it when you need to confirm what a field means, which Payload type a behaviour belongs to, or how runtime settings affect Jobs. If you are creating a Payload for the first time, start with the task articles first, then come back here when you need a concise reference.

For task guidance, start with Choose a Payload type.

Outbound sends a request from Salesforce to another system. Use it when Salesforce is the caller and the external API is the receiver.

Inbound receives a request from another system. Inbound Payloads can write to Salesforce, return Salesforce data, or do both depending on their request, response, Data Query, and Data Target setup.

Email Handler processes inbound email content. Use it when the integration starts from an email message rather than an HTTP request.

Credential Payload supports credential maintenance, such as a bearer token refresh flow. Users should not normally create this type manually. Payloads creates Credential Payloads as part of the relevant Credential setup.

Older metadata values may still exist for compatibility, including Full Callout, Outbound Webhook, API Push Into SF, API Pull From SF, and Email Service. In the current documentation and UI language, use Outbound, Inbound, Email Handler, and Credential Payload.

Payloads supports these HTTP methods where the Payload type uses HTTP:

Use the method required by the external API or inbound caller. The method is part of the runtime contract. If an inbound caller sends a method that does not match the Endpoint, Payloads rejects the request.

Payloads supports these configured content types:

JSON is the default runtime codec when a content type is blank or not recognised by the body codec factory.

Use Inbound Email only for Email Handler Payloads. For HTTP Payloads, choose the content type that matches the body the external system sends or expects to receive.

Endpoint identifies the external URL for outbound calls or the endpoint configuration used by inbound calls.

Method controls the HTTP method.

Timeout controls how long Payloads should wait for an outbound callout.

Credential links an outbound Payload to reusable authentication.

Outbound Content Type controls the format Payloads sends or returns.

Inbound Content Type controls the format Payloads expects to receive or parse.

Response Failure Policy controls how Payloads decides whether an HTTP response should fail the Job.

These fields are worth reviewing together because they define the runtime contract. A Payload can have a correct body model but still fail if the method, endpoint, content type, Credential, or response policy does not match the external system.

Ignore Response Status means Payloads does not fail the Job based only on the HTTP response status.

Fail On Non 2xx means Payloads treats responses outside the 200 to 299 range as failures.

Custom Range means Payloads uses the configured success-code start and end values.

Use the strictest policy that matches the API contract. If the external API returns meaningful non-2xx responses that should still be processed, model that intentionally rather than ignoring statuses by default.

The response policy is one of the main settings that decides whether a Job is marked Completed or Failed after an outbound callout.

Each Payload can control retention for Jobs in New, Completed, and Failed status.

Use these fields with the cleanup service to keep Job storage under control while preserving enough history for support. Failed Jobs are often kept longer than Completed Jobs because they contain the evidence needed to diagnose problems.

For setup steps, see Configure Job retention and cleanup.

XML Declaration, XML Doctype, and XML Processing Instructions apply when XML content needs document-level options.

Set these only when the receiving system expects them. Extra XML document settings can make the generated body harder to compare with the external system's examples.

For more detail, see Model XML content.