Use an Outbound Webhook Payload when Salesforce needs to tell another system that something happened.

The request can still be detailed. You can build a body, add headers, add URL parameters, and replace parts of the URL. The difference is that the Payload is not designed around mapping a response body back into Salesforce.

If the response data matters and should be stored in Salesforce, use a Full Callout Payload instead.

Use an Outbound Webhook Payload when you need to:

The Stripe demo webhook sends a fulfilment update after payment completion. It sends a session Id, an Opportunity Id, and a payment status label to a fulfilment endpoint.

An Outbound Webhook Payload has one main configuration side: Webhook.

The Webhook section contains Dynamic Inputs, Data Queries, Body, Headers, Parameters, and Modifiers. There is no Response section with Body, Headers, or Data Targets, because this Payload type is focused on sending the event.

The Outbound Webhook layout focuses on the request Payloads sends from Salesforce, with response status handled by the Job result.

Start with the main fields on the Payload record.

For webhook-style integrations, Fail On Non 2xx is usually the clearest policy. A 4xx or 5xx response should normally create a failed Job that someone can review.

Dynamic Inputs are useful when the webhook is triggered by another part of Salesforce.

For example, a Flow might pass a record Id, a status value, or an external session Id into Payloads at runtime. The webhook can then place that value in the body, in a URL parameter, or in a URL modifier.

In the Stripe demo, the session Id is supplied as a Dynamic Input and reused in the request.

Use Data Queries when the webhook needs Salesforce data that is not passed in directly.

The query can fetch the record that triggered the event, related records, or reference data needed by the external system.

Keep webhook queries small and predictable. Event-style integrations are easier to support when each run sends one clear message.

The Body tab defines the message sent to the receiving system.

For JSON webhooks, create Elements that match the receiving API's expected shape. Each Element should have a clear source, such as a Salesforce field, Static Value, Dynamic Input, or Transformation.

For simple status notifications, keep the body small. Send the values the receiving system needs to act, not every field Salesforce knows about the record.

Use Headers for request metadata required by the receiving system.

Common examples include content negotiation headers, idempotency keys, tenant identifiers, or custom routing headers. Put authentication details in a Credential where possible.

The webhook demo uses headers for source and correlation values that help the receiving system trace the event.

Use Parameters for query string values.

Parameters are useful when the receiving API expects values in the URL rather than the request body. Keep them consistent with the external API documentation, and avoid duplicating the same value in both the URL and body unless the API requires it.

Parameters keep lightweight routing values in the URL while the event details stay in the request body.

Use Modifiers to replace placeholders inside the endpoint URL.

This is useful when the receiving API expects a URL like /sessions/SESSION_ID/status. Instead of creating a different Payload for every session, use a Modifier to replace SESSION_ID when the Payload runs.

Before you run the Payload, check that:

After a test run, open the Job record and confirm the outbound request, response status, and response body are what you expected.