Salesforce Integration Services

Direct answer: Salesforce integration connects your Salesforce org to other systems — ERP, marketing tools, billing platforms, custom applications — using one of Salesforce's several APIs: the REST API for standard record-level operations, the SOAP API for legacy enterprise systems, the Bulk API for high-volume data loads, and Platform Events for real-time, event-driven sync. Which one (or combination) you need depends on data volume, how real-time the sync needs to be, and what the system on the other end can support.

Salesforce is rarely the only system of record in a business. Finance runs a billing platform, support runs a helpdesk, operations runs an ERP — and every one of those systems eventually needs a way to read from or write to Salesforce without someone manually re-entering data. How that connection gets built determines whether Salesforce becomes a reliable hub of customer truth or one more system that quietly drifts out of sync.

What Is Salesforce Integration, and Why Do Growing Companies Need It?

Salesforce integration is the set of API connections that let other software read Salesforce data (accounts, contacts, opportunities, custom objects) or write to it, and let Salesforce push data or events out to other systems in return. Salesforce exposes this through a mature, well-documented set of APIs — which is one of the platform's genuine strengths for integration work compared to less standardized CRMs.

The need shows up as soon as a business has Salesforce as its CRM and any other meaningful system of record. A common early trigger is finance needing accurate account and opportunity data in a billing system without someone manually copying deal terms after every close. A later trigger is support needing live account status and contract data inside the helpdesk so agents aren't asking customers to repeat information already sitting in Salesforce. Left unintegrated, these gaps produce the same failure mode every time: staff manually re-keying data between systems, which is slow, error-prone, and gets worse as headcount and deal volume grow.

This pattern shows up across industries, not just general B2B sales — our healthcare CRM development and real estate CRM development guides cover the same integration logic applied to industry-specific systems of record, where the same manual re-keying problem tends to show up around scheduling, billing, or listing data instead of generic account data.

REST API vs SOAP API vs Bulk API: Which Salesforce API Should You Use?

Salesforce offers multiple APIs because different integration needs have genuinely different shapes, and picking the wrong one is a common source of avoidable cost and complexity.

API	Best for	Data volume	Notes
REST API	Standard CRUD operations on individual records; most custom app and web integrations	Low to moderate, real-time	JSON-based, easiest to work with for modern web and mobile integrations
SOAP API	Legacy enterprise systems, some ERP and middleware platforms that only speak SOAP	Low to moderate, real-time	XML-based, still common in older enterprise landscapes
Bulk API	Large-scale data loads — migrations, nightly syncs, bulk updates	High volume (thousands to millions of records)	Asynchronous, processes in batches, designed specifically to avoid governor limits on large jobs
Platform Events	Real-time, event-driven architecture — notify other systems the instant something changes	Any volume, event-driven	Built on a publish-subscribe model; ideal for triggering downstream workflows without polling

For most custom integrations connecting Salesforce to a modern SaaS tool or internal application, the REST API is the default choice. The Bulk API becomes necessary once you're moving volumes that would otherwise hit Salesforce's API call and governor limits. SOAP mostly shows up when the system on the other end — often an older ERP or middleware platform — doesn't support REST at all.

It's worth understanding why Salesforce enforces separate limits per API rather than one shared quota. REST and SOAP calls each count against a daily API request limit tied to your org's edition and license count — every single record read or write is one call. The Bulk API works differently: it groups records into batches and processes them asynchronously, so loading fifty thousand records counts as a handful of batch jobs rather than fifty thousand individual calls. That distinction is the entire reason the Bulk API exists — using the standard REST API for a large migration or nightly sync will exhaust your org's daily limit far faster than the actual data volume would suggest, and it's one of the most common estimation mistakes teams make before bringing in a partner who has hit this limit before.

There's also a fourth consideration worth flagging separately from the table above: the Composite API, which lets you bundle multiple REST calls into a single request. It doesn't replace REST, Bulk, or Platform Events, but it's a useful tool for reducing API call consumption on integrations that need to perform several related operations — creating a record and then immediately updating a related one, for example — where making two separate REST calls would otherwise cost two units against your daily limit instead of one.

How Do Platform Events Enable Real-Time Salesforce Integration?

Platform Events are Salesforce's native pub-sub (publish-subscribe) mechanism: when something happens in Salesforce — an opportunity closes, a case status changes, a custom business event fires — Salesforce publishes an event that any subscribed external system receives immediately, without polling.

This matters because polling Salesforce for changes (repeatedly asking "anything new?") is inefficient and eats into your org's API call limits, which are finite and shared across every integration connected to that org. Platform Events flip the model: your external system subscribes once, and Salesforce pushes the event the moment it happens. This is the closest Salesforce equivalent to a webhook, and it's the right tool when a downstream system — a billing platform, a notification service, a data warehouse — needs to react to Salesforce changes in near-real time rather than finding out on the next scheduled sync.

How Do Webhooks and Outbound Messages Work in Salesforce?

Salesforce's older mechanism for pushing data out is the Outbound Message, configured through a workflow rule or process builder flow, which sends a SOAP message to an external endpoint when a defined condition is met. It works, but it's SOAP-based, harder to debug than a modern webhook, and increasingly considered a legacy pattern as Salesforce pushes Platform Events and Flow-based automation as the current best practice.

For teams building new integrations today, the more common pattern is a Salesforce Flow (or Apex trigger) that calls out to an external REST endpoint directly, or a Platform Event that an external system subscribes to via Salesforce's CometD-based streaming API. Either approach gives you the near-real-time behavior a modern webhook provides, without relying on the older outbound message mechanism.

How Much Does Salesforce Integration Cost?

Cost depends primarily on which Salesforce API the integration uses, how much custom Apex logic is needed inside Salesforce itself, and how many external systems are involved.

A straightforward, single-direction REST API integration — syncing leads or contacts from a web form or another tool into Salesforce — fits our Essential tier at $1,000.

Growth tier projects at $2,000 typically cover bidirectional sync between Salesforce and one other system (a billing platform or marketing tool, for example), including basic conflict handling and either scheduled polling or a Platform Event-based real-time trigger.

Enterprise tier at $4,000+ covers multi-system Salesforce integrations, Bulk API-based data migrations or nightly syncs at volume, custom Apex development for business logic that needs to live inside Salesforce itself, and integrations requiring audit trails for compliance. Full pricing detail is on our pricing page.

The variable that most often moves a project from one tier to the next isn't the integration code itself — it's how much of the work happens inside Salesforce versus outside it. A REST integration that only reads and writes standard fields on standard objects is comparatively simple to scope. The same integration against a heavily customized org — custom objects, validation rules that reject records the integration doesn't expect, existing Apex triggers that fire on the same events the integration touches — takes meaningfully longer to build and test safely, because the integration has to be designed around logic that already exists in the org rather than a clean slate.

How Long Does a Salesforce Integration Project Take?

A single-direction REST integration between Salesforce and a modern SaaS platform typically takes two to four weeks, including field mapping (Salesforce's object and field structure is highly customizable, so this step takes longer than with a simpler CRM), authentication setup, and testing.

Bidirectional integrations, or ones involving Platform Events for real-time sync, usually run four to eight weeks. Bulk API-based data migrations or high-volume nightly syncs, and integrations touching custom Apex logic, commonly run eight to fourteen weeks depending on how much custom logic already exists in the org and how well-documented the customizations are. Our methodology page covers how we structure discovery for Salesforce projects specifically, since org customization is usually the biggest source of estimate variance.

A discovery phase that maps existing Apex triggers, validation rules, and workflow automation before any integration code gets written is what keeps these estimates honest. Skipping that step is the most common reason Salesforce integration timelines slip — not because the API is hard to work with, but because an integration written against an assumed-clean org runs into an existing validation rule or trigger mid-build that rejects records the integration didn't expect to be rejected.

Do You Need a Salesforce Developer, or Can Native Connectors Handle It?

Salesforce's AppExchange marketplace has native connectors for many popular platforms, and for a standard use case with a mainstream tool, a native connector or a middleware platform like MuleSoft (Salesforce's own integration platform) can genuinely be the faster, cheaper path. If your Salesforce org is largely out-of-the-box and the system you're connecting to is common, start there.

You need custom development once your org has significant customization (custom objects, custom fields, non-standard business logic in Apex triggers or flows), once the integration needs conditional logic a native connector doesn't support, or once you're integrating a less mainstream system that doesn't have an existing connector. Our custom software development team scopes Salesforce integration work with an org-specific discovery phase, because the actual complexity almost always lives in how customized the org already is, not in the API itself. Relying too heavily on a proprietary connector or middleware layer also has a downstream cost worth weighing upfront — our guide on avoiding software vendor lock-in covers how to keep an integration portable rather than tightly bound to one vendor's tooling.

Is Salesforce Integration Secure?

Salesforce integration security rests on a few concrete practices: OAuth 2.0 for authentication (Salesforce supports several OAuth flows depending on whether the integration is server-to-server or user-facing), connected apps with scoped permissions rather than a single admin credential shared across every integration, and field-level security so an integration only reads or writes the fields it genuinely needs.

A common mistake is building an integration on a personal user's credentials rather than a dedicated integration user with its own profile and permission set — this makes the integration fragile (it breaks if that person leaves or changes roles) and makes audit logging much harder to interpret. A dedicated integration user, scoped OAuth connected app, and field-level security review should be standard on every Salesforce integration, not an enterprise-tier add-on.

What Can Go Wrong With a Salesforce Integration?

The most common failure mode is hitting Salesforce's API call limits — every org has a daily cap on API calls that scales with license count and edition, and an integration that polls too frequently or processes records one at a time instead of in bulk can burn through that limit faster than expected, blocking every other integration connected to the same org.

Other recurring issues: governor limit errors on Apex-based integrations (Salesforce enforces strict limits on execution time, SOQL queries per transaction, and DML operations to protect shared infrastructure), data mapping breaking silently when a custom field gets renamed or deleted in the org, and duplicate records being created because the integration doesn't check for an existing match before inserting. Each of these is preventable with the right upfront design — using the Bulk API for volume, using external ID fields for reliable upsert matching, and monitoring API usage against the org's limit — but each is also easy to miss if the integration is built without Salesforce-specific experience.

A less obvious failure mode is sandbox-to-production drift: an integration built and tested against a Salesforce sandbox can behave differently in production if the sandbox doesn't have the same validation rules, workflow automation, or data volume as the live org. Refreshing sandboxes regularly and testing against a sandbox that mirrors production configuration — not just an empty developer org — is a detail that separates integrations that work in testing and then break on day one from ones that don't.

How Do You Test a Salesforce Integration Before Go-Live?

A Salesforce integration pre-launch checklist:

• Test authentication and the connected app's OAuth flow, including token refresh
• Confirm field-level security allows exactly the access the integration needs — no more
• Run the full sync against a Salesforce sandbox before touching production data
• Test upsert logic with external ID matching to confirm no duplicate records get created
• Simulate hitting the API call limit and confirm the integration backs off gracefully
• Test Bulk API jobs with a realistic data volume, not a handful of sample records
• Confirm Platform Event subscribers handle events arriving out of order or more than once
• Verify custom Apex triggers don't create governor limit errors under expected load
• Confirm error logging surfaces failed records rather than silently skipping them
• Run a rollback test to confirm the integration can be disabled without leaving the org in an inconsistent state

Common Systems Businesses Integrate With Salesforce

The most frequent Salesforce integrations we build connect it to ERP systems (so order and inventory data flows into the CRM without manual entry), marketing automation platforms (for lead scoring and campaign attribution), billing and subscription platforms (so finance and sales share the same account and contract data), and custom internal applications built for a specific operational workflow.

ERP-to-Salesforce integrations deserve a specific mention because they're often the most involved: an ERP holds inventory, pricing, and order fulfillment data that sales needs visibility into from inside an opportunity or account record, while Salesforce holds the customer relationship and deal context the ERP has no concept of. Getting this right usually means Salesforce as the system sales and support work from day to day, with the ERP feeding it order status and inventory data through a scheduled or event-driven sync, rather than trying to make either system the sole source of truth for everything. Marketing automation integrations tend to be more straightforward by comparison — mostly lead and campaign data flowing in one primary direction, with engagement scores flowing back — but they still benefit from the same discipline around field mapping and duplicate prevention as any other integration.

If you're weighing Salesforce against a custom-built CRM rather than integrating around it, our custom CRM development cost guide and our broader custom CRM development guide cover that build-versus-buy decision directly, and our broader custom API integration services guide covers the general patterns — REST, webhooks, rate limits — that apply across any integration project, Salesforce included. Our API-first software design guide is a useful companion read if you're also designing a custom application meant to integrate cleanly with Salesforce and other systems from day one.

Many Salesforce integration projects also touch a second CRM-adjacent platform during a migration or consolidation; our HubSpot integration services guide covers the equivalent patterns on that platform if you're running both. For businesses handling payment or billing data as part of the sync, our payment gateway integration guide covers the additional security and compliance considerations that apply once financial data enters the picture.

Key Takeaways

• Salesforce offers four main integration APIs — REST, SOAP, Bulk, and Platform Events — and picking the right one for your volume and real-time requirements is the first architectural decision.
• Platform Events are Salesforce's modern, near-real-time push mechanism and the closest equivalent to a webhook; Outbound Messages are the older, SOAP-based, largely legacy pattern.
• Pricing runs $1,000 for a simple one-direction REST sync, $2,000 for bidirectional sync, and $4,000+ for multi-system or Bulk API-driven projects with custom Apex logic.
• Org customization — not the Salesforce API itself — is usually the biggest driver of project timeline and cost.
• A dedicated integration user with scoped OAuth permissions, not a shared admin login, is the security baseline for every Salesforce integration.
• API call limits and governor limits are the most common cause of integration failures at scale; bulk operations and external ID-based upserts prevent most of them.
• Native AppExchange connectors and MuleSoft are legitimate options for standard use cases; custom development becomes necessary once the org or the workflow gets non-standard.

Ready to connect Salesforce to the rest of your stack without the manual data entry? Book a meeting to scope your integration.