Salesforce real-time integrations: Platform Events vs Outbound Messages vs Webhooks

When an organisation wants Salesforce to notify an external system in real time, ERP, MDM, marketing tool, logistics platform, three native patterns are available: Platform Events, Outbound Messages and custom Webhooks via Apex. Choosing the wrong pattern generates fragile architectures, data loss or costly maintenance. Here's how to choose.

The 3 patterns in brief

Platform Events : the modern pattern

Platform Events are Salesforce's native event-driven integration mechanism, introduced in Spring '17. They rely on a message bus (CometD / Bayeux protocol) that decouples Salesforce from the consuming system.

How it works

• Define a Platform Event object (like a custom Salesforce object, with fields)
• Salesforce publishes an event via Apex (EventBus.publish()) or a Flow
• Subscribers, external systems, other Salesforce orgs, Apex triggers, consume events by subscribing to the /event/MyEvent__e channel
• Events are retained for 72 hours, if a consumer is temporarily unavailable, it can resume from where it left off

Strengths

• Full decoupling, Salesforce doesn't know who consumes the event, or if anyone does. No dependency on the target system's availability.
• 72h retention and replay, consumers can replay missed events via a ReplayId
• Governor limit friendly, publishing a Platform Event doesn't count as a DML in Apex limits
• Multi-consumer, multiple systems can subscribe to the same event

Limitations

• The consumer must maintain an active CometD connection or be a compatible system (MuleSoft, Heroku, ESB…)
• No guarantee of event ordering in all cases
• Monthly event allocation varies by licence (250,000 to several million depending on edition)

Outbound Messages : the legacy pattern

Outbound Messages have existed since Salesforce's early days. Configured via Workflow Rules (now deprecated) or Process Builders (also deprecated), they send a SOAP message to an external endpoint when a record meets certain criteria.

How it works

• Declarative configuration in Workflow Rules: "when opportunity moves to Closed Won, send an Outbound Message"
• Salesforce automatically sends a SOAP payload with configured fields to the endpoint
• The endpoint must respond with an Ack (acknowledgement), otherwise Salesforce retries for 24 hours

Strengths

• Zero code, 100% declarative configuration
• Native retry, Salesforce handles retries automatically for up to 24 hours
• Delivery guarantee, with Ack, you know the message was received

Limitations

• Dependent on Workflow Rules, which are deprecated by Salesforce. Creating new Outbound Messages is not recommended today.
• SOAP only, few modern systems expose native SOAP endpoints
• Limited payload, only configured fields are sent, no dynamic logic
• Single endpoint per message, no native multi-consumer

Webhooks via Apex Callout : the custom pattern

When neither Platform Events nor Outbound Messages fit, you can make a direct HTTP call from Apex to an external endpoint, commonly called a "Salesforce webhook", even though Salesforce has no native webhook mechanism in the strict sense.

How it works

• An Apex trigger, Flow or invocable action calls an Apex method marked @future(callout=true) or implementing Queueable
• The method makes an HTTP REST call to the external endpoint with the desired payload
• The endpoint responds, Salesforce receives the response but only processes it if the code handles it

Strengths

• Total flexibility, custom payload, personalised headers, OAuth authentication, business logic in the payload
• REST compatible, integrates with any modern HTTP endpoint
• Usable response, code can read the response and act accordingly (update a field, log an error…)

Limitations

• No native delivery guarantee, if the endpoint is unavailable, the message is lost unless retry logic is implemented
• Callout impossible in a synchronous trigger, must use @future or Queueable, introducing asynchronism
• Callout governor limits, 100 callouts maximum per transaction
• Maintenance complexity, authentication, error handling, retry, logging, all must be coded

Summary comparison

How to choose

Choose Platform Events if…

• You have an ESB, middleware (MuleSoft, Azure Service Bus, Kafka) or platform capable of subscribing to a CometD channel
• Multiple systems need to consume the same event
• Event retention and replay matter for your use case
• You want clean decoupling between Salesforce and target systems

Choose Apex Callout if…

• The target system exposes a REST endpoint and cannot subscribe to a message bus
• You need a usable synchronous response (retrieve an external ID, check availability…)
• The payload must be dynamically built with complex business logic

Don't choose Outbound Messages for new development

Simple. Workflow Rules are deprecated, SOAP is ageing, and Platform Events cover all Outbound Message use cases with more flexibility.

Conclusion

In 2026, Platform Events is the pattern to prioritise for new Salesforce event-driven integrations. It offers decoupling, retention and multi-consumer support, without the compromises of Outbound Messages or the complexity of Apex Callouts. Reserve Apex Callouts for cases where you need a usable synchronous response or a very custom payload that Platform Events cannot express simply.