Use an outbound webhook when Salesforce needs to tell another system that something happened.

In Payloads, a webhook is configured as an Outbound Payload. The request can still have a body, headers, URL parameters, and URL modifiers. The difference is the goal: a webhook usually cares that the receiving system accepted the event, not that Salesforce stores detailed response data.

For the fuller request and response pattern, see Configure an Outbound Payload.

Use this pattern 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.

Start with an Outbound Payload.

The Request section contains Dynamic Inputs, Data Queries, Body, Headers, Parameters, and Modifiers. You can leave the Response Body and Data Targets empty when the response body is not useful to Salesforce.

A webhook-style Outbound Payload focuses on the request Payloads sends from Salesforce, with delivery success handled by the Job result.

Start with the main fields on the Payload.

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.