How to Use Webhooks in Salesforce

A Salesforce webhook integration sends or receives an HTTP request when an event happens. You can send outbound requests with Flow HTTP Callout, Declarative Webhooks or Apex. To receive incoming webhooks, use a compatible endpoint such as a Declarative Webhooks inbound template or an Apex REST resource.

The right choice depends on the direction of the data, the receiving API’s requirements, and how your team wants to maintain the integration. Declarative Webhooks is a no-code tool for sending and receiving HTTP requests, with configurable templates, Call Logs and retry options. Apex extensions are available when a specific requirement needs custom logic.

This guide explains the options, walks through an outbound integration, and covers receiving webhooks, signing and safe retries. For more background, see our introduction to webhooks.

Are you sending or receiving a Salesforce webhook?

Outbound: Salesforce sends a request to an external application. For example, an Opportunity becomes Closed Won and Salesforce requests customer onboarding.

Inbound: An external application sends a request to Salesforce. For example, an onboarding system reports completion and Salesforce updates the related Opportunity.

One integration can use both directions. Receiving an HTTP response to an outbound request is different from exposing an endpoint for incoming webhooks.

Choose your Salesforce webhook integration method

Direction below is relative to Salesforce.

Method	Direction	Best suited to
Flow HTTP Callout	Outbound HTTP	Configuring a request to a compatible external REST API
Declarative Webhooks	Inbound and outbound HTTP	Configurable templates, signing or signature validation, response actions, logs and delivery recovery
Apex HTTP callout	Outbound HTTP	Developing and maintaining the request implementation directly in code
Apex REST resource (@RestResource)	Inbound HTTP	Exposing a custom endpoint with Apex processing logic
Outbound Message	Outbound SOAP	Receivers that support Salesforce’s SOAP message and acknowledgment contract
Platform Events	Inbound and outbound events	Publishing and subscribing to business events
Change Data Capture (CDC)	Outbound record-change events	Notifying external subscribers about Salesforce record changes

Flow HTTP Callout sends requests and can process their responses; it does not create an incoming webhook endpoint. Likewise, an Apex HTTP callout sends a request out, while an Apex REST resource accepts a request in. An Apex integration can combine both. Salesforce Flow integration options

Platform Events support two-way asynchronous messaging, while CDC notifies subscribers about record changes. These event-based options require subscribers rather than simply a destination webhook URL. A bridge can forward their events as HTTP requests when needed. Platform Events · Change Data Capture

Salesforce products can also have dedicated webhook features, such as Data 360 webhook data action targets. Check the product and workflow before choosing an implementation.

Send a Salesforce webhook with Declarative Webhooks

Suppose you want a Closed Won Opportunity to start onboarding in another application. The destination accepts a JSON POST and returns an onboarding ID.

The following example shows how to structure that integration. Use a sandbox and synthetic records while configuring and testing it. Screenshots are drawn from the existing DW user guide and illustrate the relevant controls; sample data and interface details may differ from your org.

1. Define the destination and request

Confirm the destination URL, authentication, required fields and success response with the receiving system’s owner. Decide how that service will recognize a duplicate request.

Here is an illustrative payload; your receiving API determines the actual schema:

{
  "event_id": "onboarding-request-000123",
  "event_type": "opportunity.closed_won",
  "opportunity_id": "006XXXXXXXXXXXXXXX",
  "account_id": "001XXXXXXXXXXXXXXX",
  "amount": 10000
}

Generate and persist an event ID for each logical onboarding request, then reuse it for retries. An Opportunity ID alone may not distinguish separate events if a deal is reopened and won again. Send only the fields the destination needs.

2. Create a Callout Template

In Declarative Webhooks, create a Callout Template with Opportunity as the Main Object. Set the method to POST, enter the destination URL, and select authentication that matches the receiving API. Named Credentials are one supported option.

Configure any required headers and map the request body’s fields to the Opportunity and related records. Use the expected response structure to identify values returned by the destination. Create an outbound connection

Keep credentials out of source code and ordinary text configuration. Use an appropriate credential mechanism and review access to sensitive integration data. Salesforce credential guidance

The JSON builder lets you create the request structure or generate it from sample JSON and Salesforce fields. Source: DW user guide.

3. Configure what happens after the response

For a successful response, use a response action to save the external onboarding ID to a Salesforce field you have created for that purpose. Define the conditions under which the action should run.

Check both the HTTP status and the API’s business result. A 2xx response might mean that the destination accepted work for later processing rather than completed onboarding. Response actions

4. Test the template before automating it

Use the template’s Test action with a sample Opportunity. Review the generated URL, headers and body before sending. The test makes a real request and can change records, so use the destination’s test environment too.

Confirm that the receiver obtains the intended data and that the expected Salesforce response action runs. Test a Callout Template

Preview the generated request before sending. This user-guide example uses Contact test data and Postman Echo, rather than the Opportunity scenario above. Source: DW user guide.

5. Invoke the template from a record-triggered Flow

Configure an after-save Opportunity Flow to run when the record enters Closed Won, rather than on every later edit while it remains won. Decide separately whether reopening and winning a deal should start another onboarding request. Ensure that saving the returned onboarding ID or processing an inbound status update does not trigger another onboarding request; use entry criteria based on the intended business transition.

Add DW’s Invoke Callout action, reference the template by Developer Name, and pass the triggering Opportunity’s ID. This documented DW action initiates an asynchronous callout; the HTTP request runs in a separate transaction. A completed Flow does not by itself confirm delivery. DW record-triggered Flow setup

Select Invoke Callout (Using Developer Name) to reference the configured DW template from Flow. This is a packaged action you configure; you do not need to write Apex to use it. Source: DW user guide.

6. Check delivery and recovery

Trigger the workflow with a test record and inspect its Call Log and the receiver’s result. Test invalid credentials, rejected data, a temporary failure and a duplicate event.

Configure automatic retries for supported automatic callouts according to the receiver’s contract. DW distinguishes manual retries from automatic retries; a manual template test does not exercise the same automatic retry path. Retry support

The test results show the response and affected records, with a link to the Call Log. This is the user guide’s Contact/Postman Echo example, not a test of the onboarding workflow. Source: DW user guide.

Use native Flow HTTP Callout for outbound requests

Salesforce also lets you configure outbound REST requests without custom Apex using Flow HTTP Callout. Set up the endpoint and authentication, create the HTTP Callout action, and map its request and response data.

For a record-triggered Flow, use an appropriate asynchronous path for the native external callout after the record transaction commits. This setup differs from DW’s Invoke Callout action described above, which handles asynchronous dispatch through the app. Salesforce record-triggered Flow considerations

Native Flow HTTP Callout is worth evaluating for a straightforward compatible API. Compare the full workflow—including authentication, transformations, response processing, logs and delivery recovery—when choosing between native Flow, DW and a custom implementation.

Build and manage Salesforce integrations without code

Declarative Webhooks lets Salesforce admins configure outbound HTTP requests and process their responses without writing code. Define the endpoint, authentication, headers and request body in a Callout Template, then use it from Flow or another supported entry point.

DW adds tools for managing the integration after setup. Call Logs help you inspect requests and responses, response actions let you act on returned data, and configurable retries help recover from failed automatic callouts. You can also create inbound templates to receive webhooks and update Salesforce records—covering both directions in the same tool.

For the onboarding example, an admin can map Opportunity fields, send the request, save the returned onboarding ID and review delivery through configuration. No custom Apex is required for that workflow.

Add Apex only when a requirement needs it

If you encounter a requirement that needs custom logic, you can extend the existing DW integration. For example, generate a complex request-body node or header with Apex, run custom logic in a response or inbound action, or invoke a configured template from existing Apex code. The rest of the integration can remain declarative.

See the user guide for Apex-generated body nodes, custom URLs and headers, and calling DW from Apex.

Receive webhooks in Salesforce and validate signatures

To receive a webhook with DW, create an Inbound Call Template, configure its method and authentication, define the expected request, and choose the actions and response. For the onboarding example, identify the Opportunity from the incoming payload and update its onboarding status. Create an inbound connection

DW supports request signing and inbound signature validation, with Apex extensions for custom requirements. Its guide documents signed-body authentication and custom Apex verification. Match the provider’s exact algorithm, encoding, signed content and headers to the selected configuration. Inbound authentication options

Some providers also send an endpoint-verification challenge before delivering events. DW supports identifying those requests and using an Apex validation class to produce the required reply. That challenge is separate from authenticating subsequent webhook deliveries. Webhook validation

Test a valid request and an invalid credential or signature. DW’s inbound test includes a Skip Authentication option: turn it off to exercise authentication. Then verify a request from the actual sending system. Inbound testing

With custom Apex, an @RestResource class and an HTTP handler such as @HttpPost can expose an inbound endpoint. If an existing Salesforce API already meets the need and the sender supports its authentication, a custom endpoint may be unnecessary. Salesforce Apex REST guidance

Make webhook retries safe

Suppose a failed onboarding request contains an amount of 10,000. Before you retry it, someone changes the Opportunity amount to 12,000.

Should the retry resend the original event or synchronize the current record?

• Replay the event: resend the original 10,000 payload using its original event identity.
• Send current data: rebuild from the updated 12,000 record using identity and version rules appropriate to that request.

DW’s manual retry options distinguish reusing logged request details from rebuilding the request from record data, subject to the documented conditions. Choose intentionally: a receiver may ignore a changed payload if its event ID has already been processed. Manual and automatic retry behavior

Use duplicate handling at the receiver, and define how you will identify requests that remain incomplete after recovery attempts. A timeout can occur after the receiver has already processed the request, so retrying without duplicate protection can create a second onboarding record.

Troubleshoot common Salesforce webhook failures

Symptom	Check first
No outbound request arrives	Flow activation, entry criteria, queued work and destination URL
401 or 403	Credentials, signature rules and required permissions
400 response	Required fields, data types and the receiver’s validation rules
429 or temporary server failure	Rate limits and a bounded retry policy following the receiver’s contract
Duplicate external records	Stable event IDs and duplicate handling at the receiver
Old data overwrites new data	Version checks and out-of-order delivery handling
HTTP success without the expected outcome	Response body, downstream processing and reconciliation

Salesforce SOAP Outbound Messages have a separate delivery contract. They provide delivery monitoring and retries, and require the receiver to handle acknowledgments and possible duplicate or out-of-order notifications. They are not interchangeable with an endpoint expecting a JSON POST. Outbound Message considerations

For a platform-specific implementation, see our Salesforce-to-Mailchimp integration example.

Frequently asked questions about Salesforce webhooks

Does Salesforce support webhooks natively?

Salesforce supports outbound HTTP requests through Flow HTTP Callout and Apex, and custom inbound endpoints through Apex REST. Some Salesforce products also have dedicated webhook features. Choose based on the product, direction and API contract.

Can Flow HTTP Callout receive incoming webhooks?

No. It sends outbound requests and processes their responses. Receiving a webhook requires a compatible inbound endpoint, such as a DW Inbound Call Template or an Apex REST resource.

Can I use Declarative Webhooks with existing Apex?

Yes. Apex can invoke DW templates and sequences, and extend request generation, authentication, inbound processing and response actions. You can keep ordinary mappings configurable and code the custom parts.

How do I prevent duplicate records when retrying webhooks?

Give each logical event a stable ID and make the receiver recognize repeat deliveries. Decide whether retries replay the original request or send current data, and test duplicate handling before enabling automatic retries.

Build your first Salesforce webhook integration

Start with one workflow and prove its request, authentication, response and failure recovery. Declarative Webhooks provides configurable inbound and outbound integration templates, with Apex extensions when your requirements need custom logic.

Explore Declarative Webhooks · Create an outbound template · Create an inbound template