Here is a scenario I encounter on almost every enterprise Salesforce engagement. A new opportunity is closed-won in Salesforce. The ERP needs to be notified to kick off fulfilment. The architect says: “We’ll call the ERP API when the record is saved.” Simple. Done. Except three months later, the ERP team is drowning in duplicate orders during peak load, the Salesforce org has an 8-second save time for Opportunity records, and no one can explain why 3% of orders silently failed.

The technology was correct. The pattern was wrong.

The three patterns we cover in this article (Salesforce APIs, Platform Events, and Webhooks) are not just different technologies. They represent fundamentally different philosophies about how systems communicate, who is responsible for delivery, and what happens when something goes wrong. Getting this choice right at design time prevents an entire class of production incidents.

Before we go deep on architecture, let me give you the mental model I use when explaining this to everyone from junior developers to C-suite executives. It works every time.

Salesforce exposes several API flavours including REST, SOAP, Bulk, Streaming, Composite, and more. They all share one fundamental characteristic: they are request-response patterns. The calling system asks a question and waits for an answer before proceeding. This blocking behaviour is both their strength and their limitation.

When the API Is the Right Tool

Use a Salesforce API when you need an immediate, confirmed answer. Retrieving a specific Account record to display in a third-party portal. Creating an Order in Salesforce when a customer checks out on your e-commerce platform and you need the Salesforce record ID back immediately to display a confirmation. Checking whether a Lead already exists before creating a new one. These are all phone-call scenarios where you need the other party to pick up and respond before you can move on.

API Types at a Glance

Sample: REST API Call from External System into Salesforce

// External system creates a Lead in Salesforce via REST API
// POST /services/data/v59.0/sobjects/Lead/

const response = await fetch(`${instanceUrl}/services/data/v59.0/sobjects/Lead/`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${accessToken}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    FirstName: 'Jane',
    LastName:  'Doe',
    Company:   'Acme Corp',
    Email:     '[email protected]',
    LeadSource: 'Web'
  })
});

// Caller WAITS here. Execution is blocked until Salesforce responds.
const result = await response.json();
console.log(`Lead created with ID: ${result.id}`); // ← need this ID immediately
JavaScript · REST API

Platform Events are Salesforce’s implementation of the publish-subscribe (pub-sub) pattern. A publisher fires an event onto the Salesforce Event Bus and immediately returns. It does not wait. It does not check if anyone is listening. It broadcasts the signal and moves on. Subscribers (Apex triggers, Flows, MuleSoft, external systems via CometD) independently consume those events at their own pace.

This architectural pattern eliminates the most common causes of Salesforce integration failure: synchronous coupling, governor limit breaches on triggers, and cascade failures when a downstream system is unavailable.

How Platform Events Work: Architecture View

Defining and Publishing a Platform Event

// Step 1: Define your Platform Event in Setup (or via Metadata API)
// Object: Order_Placed__e
// Fields: OrderId__c (Text), CustomerId__c (Text), Amount__c (Number), Status__c (Text)

// Step 2: Publish from Apex (e.g. when Opportunity is Closed Won)
trigger OpportunityTrigger on Opportunity (after update) {
    List<Order_Placed__e> events = new List<Order_Placed__e>();
    
    for (Opportunity opp : Trigger.new) {
        if (opp.StageName == 'Closed Won' && 
            Trigger.oldMap.get(opp.Id).StageName != 'Closed Won') {
            
            events.add(new Order_Placed__e(
                OrderId__c    = opp.Id,
                CustomerId__c = opp.AccountId,
                Amount__c     = opp.Amount,
                Status__c     = 'New'
            ));
        }
    }
    
    // Publish: returns IMMEDIATELY. Trigger does not wait for subscribers.
    EventBus.publish(events);
}
Apex · Platform Event Publisher

// Step 3: Subscribe via Apex Trigger on the Platform Event
trigger OrderPlacedSubscriber on Order_Placed__e (after insert) {
    for (Order_Placed__e event : Trigger.new) {
        // This runs asynchronously, fully decoupled from the publisher
        OrderService.createFulfilmentRecord(
            event.OrderId__c,
            event.CustomerId__c,
            event.Amount__c
        );
    }
}
Apex · Platform Event Subscriber

Platform Events vs. Change Data Capture (CDC)

A common point of confusion: Salesforce also offers Change Data Capture (CDC). These are automatic events fired whenever a standard or custom object record changes. The difference is intent. Platform Events are business events you deliberately define and publish: “An order was placed.” CDC events are data-layer change signals: “The Account record with ID 001XYZ was updated, here are the changed fields.” Use Platform Events for business process events. Use CDC when an external system needs to sync Salesforce data changes in near-real-time without polling the API.

Webhooks are not a Salesforce-native concept. They are an industry-standard pattern used by virtually every modern SaaS platform: Stripe, Shopify, GitHub, Twilio, Slack, HubSpot, and hundreds more. Understanding webhooks is essential for any Salesforce architect because Salesforce is almost never an island. It lives inside an ecosystem of external platforms that need to push data into it when things happen.

The webhook pattern is simple: an external system registers a URL with you: “when event X happens, POST the details to this URL.” When the event fires, the external system sends an HTTP POST to your endpoint. You process it. Done. No polling. No cron jobs. No “check every 5 minutes if anything changed.”

Real-World Webhook Scenarios Every Salesforce Team Deals With

Webhook Security: Never Trust, Always Verify

// Webhook endpoint (Node.js / MuleSoft receives Stripe event)
// STEP 1: Verify the signature BEFORE processing anything

app.post('/webhook/stripe', express.raw({type: 'application/json'}), (req, res) => {
  
  const sig    = req.headers['stripe-signature'];
  const secret = process.env.STRIPE_WEBHOOK_SECRET;
  
  let event;
  try {
    // Stripe signs every payload. Verify it came from Stripe, not an attacker.
    event = stripe.webhooks.constructEvent(req.body, sig, secret);
  } catch (err) {
    return res.status(400).send(`Webhook signature verification failed`);
  }

  // STEP 2: Return 200 IMMEDIATELY, before any processing
  res.status(200).json({ received: true });

  // STEP 3: Async processing. Publish to queue or Platform Event.
  if (event.type === 'payment_intent.succeeded') {
    processPaymentAsync(event.data.object); // non-blocking
  }
});
Node.js · Webhook Receiver

Here is the decision framework I walk every architect through when we are designing a new integration. Answer these questions in order:

For Salesforce Architects and Developers

Run an integration audit. Pull up your current Salesforce org’s outbound API callouts and check your Apex classes and triggers for any synchronous HTTP callouts made from record-save contexts. Each one is a potential performance bomb and a future production incident waiting to happen. For every callout you find, ask: does the caller actually need the response synchronously? If not, that is a Platform Event candidate.

Second action: look at your external system integrations, especially your SaaS platforms like Stripe, Shopify, GitHub, or any payments/logistics provider. If any of them are being polled via scheduled jobs, check if they offer webhooks. They almost certainly do. Replace the polling job with a webhook receiver and eliminate an entire class of latency and missed-event issues.

For Business and Technology Leaders

Ask your architecture team one question: “In our Salesforce integrations, are we using synchronous API calls in places where an asynchronous event-driven pattern would be more resilient and scalable?” If they cannot answer that clearly, schedule an integration architecture review. The pattern choices made at design time are invisible until they cause an incident, and then they become the most expensive decisions in the project.

I have debugged integrations at 2am that were failing because a well-intentioned developer made an API call from a trigger that ran 200 times per second during a batch import. I have seen Platform Events replay 40,000 messages after a 3-hour subscriber outage, perfectly, with zero data loss. I have watched webhook implementations silently lose 3% of Stripe payments because someone forgot to return HTTP 200 before processing. These are not edge cases. They are patterns.

The mental models in this article (phone call, radio broadcast, doorbell) are the ones I use in every architecture review. They are simple enough for a business leader to understand and precise enough to drive the right technical decision. Use them.

Are you currently dealing with performance issues or data consistency problems in a Salesforce integration? Drop your scenario in the comments. I would genuinely like to help diagnose which pattern might be causing the issue.