AI agents are becoming much more useful when they can respond to events rather than waiting for a user to trigger them manually. In a CRM such as Salesforce, this means an agent can respond when a lead is created, an opportunity changes stage, an account is updated, or a contact record is modified.
The challenge is that Salesforce does not provide a generic, built-in webhook feature that simply sends every record change as JSON to any URL. Developers instead need to use mechanisms such as Apex triggers, Change Data Capture, Platform Events, Outbound Messages, Flow HTTP Callouts, or Salesforce Data Actions.
A practical architecture combines Salesforce record triggers with an integration layer and an AI agent backend. One example uses Apex triggers + asynchronous HTTP callouts + Nango + an AI agent, allowing changes from multiple Salesforce organizations to reach the correct application tenant and ultimately trigger an agent.
This article explains how the architecture works, the different Salesforce webhook alternatives, how to build the complete event flow, and the production considerations that matter when AI agents are allowed to act on CRM data.
What Are Salesforce Webhooks?
A webhook is an HTTP request sent automatically when an event occurs.
For example, imagine a sales representative changes an opportunity from “Proposal” to “Negotiation.” Instead of waiting for your application to poll Salesforce, Salesforce can trigger an event that eventually reaches your backend.
The basic idea is:
Salesforce record changes → event is generated → HTTP request reaches backend → event is processed → AI agent runs → agent performs an action
For an AI application, this creates an event-driven workflow.
Consider a sales automation agent:
- A new lead is created in Salesforce.
- An Apex trigger detects the change.
- An asynchronous HTTP callout sends the relevant data.
- An integration layer identifies the customer’s Salesforce connection.
- Your backend receives a signed webhook notification.
- The backend retrieves the changed record.
- The AI agent analyzes the lead.
- The agent decides what action is appropriate.
- The agent creates a Salesforce Task or performs another permitted action.
This is significantly more powerful than a chatbot that only responds when a salesperson sends a message.
Does Salesforce Have Native Webhooks?
The short answer is no, not in the generic sense developers usually mean by “webhook.”
Salesforce provides several technologies that can perform similar jobs, but they have different architectures and limitations. Nango’s comparison identifies six major alternatives: Apex triggers with HTTP callouts, Change Data Capture, Platform Events, Outbound Messages, Flow HTTP Callouts, and Event Relay.
1. Apex Trigger + HTTP Callout
An Apex trigger can execute when Salesforce records are inserted or updated. The trigger can then invoke Apex code that makes an HTTP request to an external endpoint.
This is particularly useful when an AI agent needs arbitrary JSON delivered to an application endpoint.
One important limitation is that Salesforce triggers cannot make synchronous HTTP callouts in the normal transaction. The callout therefore needs to be handled asynchronously, such as with an Apex @future(callout=true) method.
2. Change Data Capture
Change Data Capture, or CDC, publishes record change events through Salesforce’s event infrastructure.
It can be a good choice for high-volume event processing, but it does not simply POST an event to your public URL. You need a persistent subscriber using Salesforce’s event APIs.
That makes CDC powerful, but potentially more infrastructure-heavy for a straightforward AI-agent webhook workflow.
3. Platform Events
Platform Events provide an event-driven architecture for custom events.
They are useful when your application controls the event model and wants Salesforce systems to publish custom business events. Like CDC, however, consuming the events generally requires a subscriber rather than simply receiving an arbitrary HTTP POST.
4. Outbound Messages
Outbound Messages provide declarative SOAP-based notifications with built-in retry behavior.
They can be useful for traditional Salesforce integrations, but they are less convenient for modern AI applications that expect JSON payloads and REST-style APIs.
5. Flow HTTP Callouts
Salesforce Flow can make HTTP callouts from record-triggered automation.
This provides a more declarative approach, although it requires appropriate per-organization configuration such as Named Credentials. The Nango tutorial also notes that Flow HTTP Callouts do not provide the same retry behavior as some other Salesforce mechanisms.
6. Event Relay
Salesforce Event Relay can forward platform events to supported external event infrastructure, including Amazon EventBridge.
This can be attractive for organizations already operating an event-driven cloud architecture.
The Recommended AI Agent Architecture
For a customer-facing AI application supporting multiple Salesforce organizations, the architecture needs to solve more than simply sending an HTTP request.
You need to know:
- Which Salesforce organization generated the event?
- Which application user owns that connection?
- Which records changed?
- Were any events lost?
- Has the event already been processed?
- How do you prevent duplicate agent executions?
- How does the agent securely write back to Salesforce?
A useful architecture looks like this:
Salesforce
↓
Apex Trigger
↓
Async HTTP Callout
↓
Integration Layer / Nango
↓
Webhook or Sync
↓
Your Backend
↓
AI Agent
↓
Salesforce API
This separates Salesforce-specific event delivery from your AI application logic.
Nango’s example uses one integration webhook URL while embedding a connection ID in the payload so that events from different Salesforce organizations can be routed to the correct tenant.
Step 1: Let the User Connect Salesforce
The first step is authorization.
Your application can provide a Connect Salesforce button. The user authorizes their Salesforce organization through an OAuth flow.
The important principle is that your application should not need to directly handle the user’s Salesforce password or OAuth credentials.
An integration platform can manage the connection and token lifecycle while your backend stores the relationship between your application’s user and the integration connection.
For example:
Your user ID → Salesforce connection ID
That relationship becomes important later when an event arrives.
Step 2: Automatically Provision the Salesforce Webhook Infrastructure
Once the user authorizes Salesforce, your backend can provision the required Salesforce components.
The Nango implementation demonstrates automatically creating:
- A Remote Site Setting
- An Apex callout class
- An Apex trigger for each watched Salesforce object
The Remote Site Setting allows Salesforce to make the outbound HTTP request to the integration endpoint.
You might choose to monitor objects such as:
- Contacts
- Leads
- Accounts
- Opportunities
You can also extend the same pattern to custom objects.
For example, an AI sales agent may monitor:
Lead → Contact → Account → Opportunity
while an AI customer-success agent may focus on:
Account → Case → Contact
Step 3: Create an Apex Trigger
The trigger should remain as lightweight as possible.
Instead of putting all the business logic into every trigger, use a shared Apex handler.
Conceptually, the trigger performs three tasks:
- Detect the relevant record operation.
- Identify fields that actually changed.
- Send the changes to an asynchronous notification handler.
A simplified architecture is:
after insert / after update
↓
Shared Apex Handler
↓
Detect relevant changes
↓
Build JSON payload
↓
Async HTTP Callout
This approach also helps make the implementation bulk-safe.
Salesforce operations can modify many records in a single transaction. Sending one HTTP request per record can quickly create unnecessary load.
The Nango implementation instead batches changed records from a trigger invocation into one payload.
Step 4: Send an Event Payload
The webhook payload should contain enough information to identify the event without making it unnecessarily large.
A useful structure includes:
{
“nango”: {
“connectionId”: “connection-id”,
“eventType”: “opportunity.updated”
},
“object”: “Opportunity”,
“data”: [
{
“Id”: “006…”,
“Name”: “Enterprise Deal”,
“StageName”: “Negotiation”,
“Amount”: 50000
}
]
}
The important part is the connection ID.
In a multi-tenant application, thousands of Salesforce organizations may send events to the same application endpoint. Your backend must know which connection generated each event.
The integration layer can use the connection ID to route the event to the correct user’s Salesforce connection.
Step 5: Use a Sync Layer for Reliability
This is one of the most important parts of the architecture.
A webhook alone is not necessarily enough for reliable AI automation.
The Apex callout pattern can provide at-most-once delivery. If the asynchronous job fails or the receiving service is temporarily unavailable, Salesforce does not automatically provide the same reliable event-recovery mechanism you might expect from a durable message queue.
Therefore, a production system should have a reconciliation mechanism.
One approach is:
Real-time webhook + periodic polling
The webhook gives you speed.
The polling process gives you recovery.
The Nango example combines webhook-driven synchronization with hourly polling. Webhook events are saved into a records cache, while polling checks Salesforce for changes that may have been missed.
This gives you a useful balance:
| Requirement | Webhook | Polling |
| Low latency | Excellent | Poor |
| Recovery from missed events | Limited | Strong |
| Simple architecture | Yes | Yes |
| Near-real-time AI | Excellent | Limited |
| Reconciliation | No | Yes |
For AI agents, this hybrid model is particularly useful because missing one CRM update can mean missing an important customer interaction.
Step 6: Send the Event to Your AI Agent
Once your backend receives the event, it can decide whether the AI agent should run.
Not every Salesforce update needs an expensive LLM call.
For example, suppose a Contact record changes only because someone updates an internal administrative field.
You may not need to trigger the agent.
Instead, define event rules such as:
- Trigger when Lead Status changes.
- Trigger when Opportunity Stage changes.
- Trigger when an Account’s Industry changes.
- Trigger when a new high-value Opportunity is created.
- Ignore updates to internal fields.
This filtering layer can reduce cost and prevent unnecessary agent executions.
The flow becomes:
Salesforce Event
↓
Verify webhook
↓
Identify tenant
↓
Identify changed record
↓
Apply trigger rules
↓
Fetch fresh Salesforce data
↓
Run AI Agent
Step 7: Verify Webhook Signatures
Webhook security should never be an afterthought.
Your endpoint should verify that the incoming request actually came from your trusted integration service.
The Nango implementation specifically verifies the webhook signature against the raw request body and uses a webhook signing key. The API secret key and webhook signing key serve different purposes.
A secure request flow should therefore be:
Incoming request
↓
Capture raw body
↓
Verify signature
↓
Reject invalid request
↓
Acknowledge valid request
↓
Queue processing
Do not run the AI agent before validating the webhook.
Step 8: Acknowledge the Webhook Quickly
AI agents can take seconds or even minutes to complete.
Your webhook endpoint should not make the sender wait for the entire AI operation.
Instead:
- Verify the request.
- Return an acknowledgment quickly.
- Put the event into your processing queue.
- Run the agent asynchronously.
The Nango example recommends acknowledging the webhook immediately and then processing the changed records asynchronously. Its sample notes a 20-second webhook timeout.
This separation is essential:
Webhook processing ≠ AI processing
The webhook endpoint should be fast and reliable.
The AI worker can be slower and more sophisticated.
Step 9: Fetch the Fresh Record
Instead of blindly trusting the webhook payload as the complete source of truth, your backend can retrieve the changed record from the integration layer or Salesforce API.
A cursor-based model is particularly useful.
The application stores the last processed cursor for each connection and object. When another webhook arrives, it retrieves changes after that cursor.
This provides a cleaner model for processing incremental changes and helps avoid complicated timestamp calculations.
For example:
Connection: customer_123
Object: Opportunity
Last cursor: 7842
New webhook
↓
Fetch records after cursor 7842
↓
Process changes
↓
Save latest cursor
Step 10: Run the AI Agent
Now the AI agent finally receives the CRM event.
For example:
A Salesforce Opportunity changed from Proposal to Negotiation.
Your agent could be instructed to:
- Analyze the opportunity.
- Review account information.
- Check recent CRM activity.
- Identify missing sales actions.
- Create a follow-up task.
- Draft a recommended email.
- Update a Salesforce field where appropriate.
A typical agent might have tools such as:
- getSalesforceRecord
- querySalesforce
- createSalesforceTask
- updateSalesforceRecord
The Nango reference implementation demonstrates an agent receiving Salesforce record changes and writing actions back through the same connection.
Prevent AI Agent Loops
One of the easiest mistakes is creating an infinite automation loop.
Imagine:
- Salesforce Opportunity changes.
- Agent is triggered.
- Agent updates Opportunity.
- Opportunity trigger fires again.
- Agent runs again.
- Agent updates Opportunity again.
The cycle can continue indefinitely.
The solution is to carefully define which fields trigger the agent.
For example, your agent might monitor:
- Stage
- Amount
- Close Date
but ignore:
- AI-generated task IDs
- Internal processing timestamps
- Agent status fields
The Nango implementation uses changed-field detection and deliberately avoids subscribing to objects the agent itself writes to when unnecessary.
This principle is essential for any event-driven AI system.
Handle Duplicate Events and Concurrency
Webhooks can be delivered more than once or processed concurrently.
Your backend should therefore be designed for idempotency.
A useful strategy is to maintain an event or record-processing key such as:
connectionId + object + recordId + changeVersion
Before starting an expensive agent run, check whether the same change has already been processed. Concurrency also matters.
Suppose two webhook requests for the same Salesforce connection arrive simultaneously. If both workers read the same cursor before either updates it, the same record could trigger the agent twice.
The reference implementation addresses this by serializing processing per connection and model.
What About Salesforce Data Actions?
Salesforce also provides a declarative approach through Data Actions, including webhook targets.
Salesforce’s developer documentation describes using Data Actions to invoke external services through webhooks. This can be useful when Salesforce automation should call an external system without requiring the same custom Apex architecture.
The right choice depends on your use case.
For a Salesforce administrator building a declarative workflow, Data Actions and Flow can be attractive.
For a developer building a multi-tenant AI SaaS platform, Apex triggers plus an integration layer can provide more control over routing, payloads, connection management, synchronization, and application-side processing.
Salesforce Webhooks vs Polling
Polling is simple:
Every 5 minutes
↓
Ask Salesforce for changes
↓
Compare records
↓
Trigger agent
But it creates latency and unnecessary API requests.
Webhooks reverse the model:
Record changes
↓
Salesforce sends event
↓
Agent responds
For AI agents, event-driven execution is generally more natural because the agent should react to business events rather than continuously asking whether something happened.
However, relying exclusively on webhooks can create reliability problems.
That is why a webhook + reconciliation model is often stronger for production systems.
Production Best Practices
Before deploying Salesforce-triggered AI agents to customers, consider these practices.
Use asynchronous processing
Never make the Salesforce transaction wait for an LLM response.
Validate every webhook
Verify signatures before processing.
Keep triggers lightweight
Move complex logic outside the Salesforce transaction.
Make processing idempotent
Assume duplicate events can occur.
Track cursors
Maintain a durable position for each connection and object.
Reconcile periodically
Use polling or another recovery mechanism to detect missed events.
Limit agent triggers
Only trigger AI workflows for meaningful changes.
Protect against loops
Never allow agent write-backs to automatically trigger themselves indefinitely.
Batch Salesforce operations
Bulk operations are common in Salesforce. Design your system to process hundreds of records without launching uncontrolled numbers of AI requests.
Control AI costs
A single Salesforce Data Loader operation can modify many records. Consider queue limits, batching, prioritization, and rate limits before running one LLM call per record.
Keep tenant isolation
Every event must remain associated with the correct Salesforce connection and application user.
Log the complete lifecycle
For debugging, record:
Salesforce event
→ webhook received
→ sync completed
→ record fetched
→ agent started
→ tool call
→ Salesforce write-back
This makes production troubleshooting much easier.
A Complete Example
Imagine an AI sales assistant for a SaaS company.
A sales representative changes an opportunity:
Opportunity: Acme Enterprise
Stage: Proposal → Negotiation
Amount: $75,000
The event flow could look like this:
Salesforce Opportunity updated
↓
Apex Trigger
↓
Async HTTP Callout
↓
Nango Integration
↓
Webhook-triggered Sync
↓
Backend receives signed notification
↓
Fetch changed Opportunity
↓
Trigger AI Sales Agent
↓
Agent reviews Opportunity + Account
↓
Agent identifies missing follow-up
↓
Create Salesforce Task
↓
Sales representative sees new task
The important thing is that nobody manually started the agent.
The Salesforce event started it.
That is the real value of event-driven AI agents.
Final Thoughts
Connecting AI agents to Salesforce webhooks is more than simply sending an HTTP request whenever a CRM record changes.
A production architecture needs to solve authentication, event routing, asynchronous execution, reliability, synchronization, security, idempotency, tenant isolation, and agent write-back.
Salesforce offers several technologies that can act as webhook alternatives, but each has different trade-offs. For applications that need arbitrary JSON events and a straightforward external endpoint, Apex triggers with asynchronous HTTP callouts can be effective. Salesforce Data Actions, Flow, CDC, Platform Events, Outbound Messages, and Event Relay can make more sense in other architectures.
An integration layer such as Nango can simplify the multi-tenant problem by managing connections, routing events, synchronizing records, and providing a consistent path back into Salesforce. The reference implementation demonstrates a particularly useful pattern: real-time webhook events combined with hourly reconciliation, followed by signed application webhooks and AI-agent execution.
The resulting architecture is powerful:
Salesforce changes → webhook → integration layer → secure backend → AI agent → Salesforce action
Once this foundation is in place, Salesforce can become an event source for much more sophisticated AI workflows—from lead qualification and sales follow-ups to account monitoring, customer success automation, CRM data enrichment, and intelligent task creation.
The key is to treat the webhook as the event trigger, not the entire system. Reliable AI automation comes from combining fast event delivery with secure processing, durable state, reconciliation, and carefully controlled agent actions.