Salesforce Integration

Home Integrations Salesforce Integration

Overview

Salesforce is the world's most widely deployed enterprise CRM platform, used by organisations across sales, service, marketing, and operations to manage customer relationships, sales pipelines, service cases, marketing campaigns, and the business processes that run across these functions. For organisations that run Salesforce as their customer data platform, integration between Salesforce and the custom software, operational systems, and data infrastructure the organisation uses is a common and often critical requirement — data generated in operational systems needs to flow into Salesforce to keep it as the accurate record of customer activity, and data in Salesforce needs to flow to operational systems that act on it.

The Salesforce platform provides several integration interfaces. The Salesforce REST API and SOAP API for programmatic access to standard and custom Salesforce objects. The Bulk API for high-volume data operations that exceed the REST API's per-record approach. The Streaming API and Platform Events for real-time event-driven integration. The Metadata API for programmatic access to Salesforce configuration and customisation. The Connect API for Chatter and social features. And the GraphQL API (newer, expanding coverage) for flexible query-based data access.

Salesforce's data model — the standard objects (Account, Contact, Lead, Opportunity, Case, Task, Event) and the custom objects and custom fields that each Salesforce organisation adds — is the foundation that integration code must understand and correctly navigate. The relationship model between objects, the sharing and security rules that control data visibility, the validation rules that enforce data quality, and the triggers and workflow rules that fire on data changes — all of these Salesforce-specific concepts affect how integration code must interact with the platform.

We build Salesforce integrations for organisations that need to connect their custom software, operational systems, and data infrastructure to Salesforce — covering the full range of Salesforce API interfaces and the integration patterns that production Salesforce connectivity requires.

What Salesforce Integration Covers

Salesforce API authentication. Salesforce uses OAuth 2.0 for API authentication, with several flows appropriate for different integration scenarios.

Connected app: the Salesforce Connected App configuration in Setup that registers the external application — the consumer key and consumer secret that the OAuth flow uses. The OAuth scopes that control what the application can access — api for REST API access, full for full access, refresh_token for offline access with refresh tokens. The callback URL for flows that involve user interaction.

Username-password flow: the OAuth 2.0 resource owner password credentials flow for server-to-server integrations — the POST https://{instance}.salesforce.com/services/oauth2/token request with grant_type=password, the consumer key, consumer secret, username, password, and security token. The access token returned for use in subsequent API calls. Not recommended for new integrations due to security limitations but still widely used for existing server-to-server integrations.

JWT Bearer flow: the recommended approach for server-to-server integrations — the application signs a JWT assertion with a private key, and Salesforce exchanges the assertion for an access token without requiring a password. The Connected App configuration with the certificate that corresponds to the private key. The JWT claims — iss (consumer key), sub (username), aud (Salesforce login URL), exp (expiry). The token exchange endpoint that returns the access token. The JWT Bearer flow that does not require storing Salesforce user passwords in the integration.

Web Server flow: the OAuth 2.0 authorisation code flow for integrations that access Salesforce on behalf of a specific user — the user authorises the application through Salesforce's login page, the authorisation code is exchanged for access and refresh tokens. Refresh tokens for maintaining long-lived access without requiring repeated user authorisation.

Instance URL: the Salesforce instance_url returned in the OAuth token response — the base URL for subsequent API calls. Salesforce instances vary by organisation (https://na1.salesforce.com, https://eu1.salesforce.com, custom domains). The instance URL that must be used rather than a hardcoded Salesforce URL.

REST API — CRUD operations. Standard create, read, update, and delete operations on Salesforce objects.

Object record creation: the POST /services/data/v{version}/sobjects/{SObjectName} endpoint for creating records. The JSON payload with the field values for the new record. The response with the id of the created record and the success boolean. The required field validation that Salesforce enforces — missing required fields return validation errors that the integration must handle.

Record retrieval: the GET /services/data/v{version}/sobjects/{SObjectName}/{recordId} endpoint for retrieving a specific record by ID. The fields query parameter for selecting specific fields rather than returning all fields. The field-level security that may prevent the integration from reading fields the user is not permitted to see.

Record update: the PATCH /services/data/v{version}/sobjects/{SObjectName}/{recordId} endpoint for updating specific fields of an existing record. The PATCH semantics that update only the specified fields rather than replacing the entire record.

Record deletion: the DELETE /services/data/v{version}/sobjects/{SObjectName}/{recordId} endpoint for deleting a record.

Upsert by external ID: the PATCH /services/data/v{version}/sobjects/{SObjectName}/{externalIdFieldName}/{externalIdValue} endpoint for creating or updating a record based on an external identifier — the integration's own system ID mapped to a Salesforce external ID field. The upsert that avoids duplicate creation when the integration does not know whether a Salesforce record already exists for a given external identifier.

SOQL — Salesforce Object Query Language. The SQL-like query language for searching and filtering Salesforce records.

SOQL queries: the GET /services/data/v{version}/query?q={SOQL_query} endpoint for executing SOQL queries. The SOQL syntax — SELECT field1, field2 FROM ObjectName WHERE condition ORDER BY field LIMIT n. The field selection that requests only needed fields. The WHERE clause with conditions on field values, dates, and relationships. The LIMIT clause for controlling result set size.

Relationship queries: SOQL's relationship traversal syntax for queries across related objects — SELECT Id, Name, Account.Name FROM Contact WHERE Account.Industry = 'Technology' for parent-to-child relationship traversal. The nested query syntax SELECT Id, Name, (SELECT Id, Subject FROM Cases) FROM Account for child-to-parent relationship traversal.

Date literals: SOQL date literals for filtering by time period — TODAY, YESTERDAY, THIS_WEEK, LAST_WEEK, THIS_MONTH, LAST_MONTH, LAST_N_DAYS:n, LAST_N_HOURS:n. The date literal that avoids hardcoded date calculations in SOQL queries.

Query pagination: the nextRecordsUrl in the query response for fetching subsequent pages when the result set exceeds the queryLocator page size (default 2000 records). The pagination loop that retrieves all records matching the query without missing any.

Bulk API 2.0. The high-volume data operation API for inserting, updating, upsetting, and deleting large numbers of records.

Bulk job creation: the POST /services/data/v{version}/jobs/ingest endpoint for creating a bulk ingest job. The job with the object (the Salesforce object), the operation (insert, update, upsert, delete, hardDelete), the contentType (CSV), and the externalIdFieldName for upsert operations.

Data upload: the PUT /services/data/v{version}/jobs/ingest/{jobId}/batches endpoint for uploading the CSV data to the job. The CSV format with header row field names and data rows. The CSV upload that can handle files up to 100MB per upload.

Job state management: the PATCH /services/data/v{version}/jobs/ingest/{jobId} endpoint for changing job state — UploadComplete to signal that all data has been uploaded and processing should begin. The job status polling via GET /services/data/v{version}/jobs/ingest/{jobId} that checks the job state until it reaches JobComplete or Failed.

Results retrieval: the GET /services/data/v{version}/jobs/ingest/{jobId}/successfulResults and GET /services/data/v{version}/jobs/ingest/{jobId}/failedResults endpoints for retrieving the per-record results after job completion — the success records with their Salesforce IDs and the failure records with their error messages.

Streaming API and Platform Events. Real-time event delivery from Salesforce to external systems.

Platform Events: Salesforce Platform Events are custom event objects that Salesforce publishes when specific business events occur — the OrderPlaced__e event published when an order is created, the CaseEscalated__e event published when a case reaches a critical status. The Platform Event schema defined in Salesforce Setup, the Apex trigger or Process Builder flow that publishes events, and the external subscriber that receives them.

CometD subscription: the Bayeux protocol-based streaming that external systems use to subscribe to Salesforce streaming channels. The CometD handshake that establishes the streaming connection, the channel subscription for Platform Events (/event/EventName__e) or Change Data Capture (/data/ObjectName__ChangeEvent), and the message processing that handles incoming events.

Change Data Capture: Salesforce CDC that publishes change events when standard or custom object records are created, updated, deleted, or undeleted. The CDC subscription that an external system uses to maintain a synchronised copy of Salesforce data — receiving real-time notifications of every change without polling the REST API.

Replay ID: the Salesforce event replay mechanism that allows subscribers to request events from a specific point in the event log — recovering missed events after a subscription gap without losing data. The replay ID stored with the last processed event that enables resumption from the correct position.

Outbound messages and webhooks. Salesforce-initiated HTTP notifications to external systems.

Outbound messages: the Salesforce Workflow Rule or Process Builder outbound message action that sends a SOAP HTTP POST to an external URL when a workflow condition is met. The WSDL that Salesforce generates for the outbound message that defines the message structure. The external endpoint that receives the SOAP message and processes the data.

Flow-triggered webhooks: Salesforce Flow's HTTP action for sending REST webhook notifications to external systems — a more modern alternative to outbound messages that supports JSON payloads and REST endpoints rather than SOAP. The Flow that sends an HTTP callout when a record is created or updated.

Custom objects and metadata. Working with Salesforce custom objects, custom fields, and metadata programmatically.

Describe API: the GET /services/data/v{version}/sobjects/{SObjectName}/describe endpoint for retrieving the complete field-level description of a Salesforce object — all fields, their data types, their labels, their required/optional status, their picklist values. The describe endpoint that integration code uses to discover the fields available on a Salesforce object without hardcoding field names.

Metadata API: the Salesforce Metadata API for programmatic access to Salesforce configuration — custom object definitions, custom field definitions, validation rules, workflow rules, and the other metadata that defines how a Salesforce organisation is configured. The integration tooling that reads or deploys Salesforce metadata as part of automated deployment pipelines.

Picklist values: the enumOrId values for picklist fields retrieved from the describe endpoint — the API values that must be used when setting picklist field values rather than the label values displayed in the Salesforce UI.

Composite API. Reducing API call volume by combining multiple operations in a single request.

Composite request: the POST /services/data/v{version}/composite endpoint for executing up to 25 REST API requests in a single HTTP call. The composite request with the allOrNone flag (if true, all subrequests must succeed or all are rolled back) and the compositeRequest array of subrequests. Each subrequest references previous responses using @{referenceId.field} syntax — creating an Account and then a Contact linked to the new Account's ID in a single composite call.

Composite graph: the POST /services/data/v{version}/composite/graph endpoint for even more complex multi-request operations with dependency management between subrequests.

SObject Collection: the POST /services/data/v{version}/composite/sobjects endpoint for creating, updating, or deleting up to 200 records of any object type in a single request — more efficient than individual REST API calls for batch record operations that do not require Bulk API's asynchronous processing.

Apex REST and custom endpoints. Custom server-side logic exposed as REST endpoints from Salesforce.

Apex REST: the Salesforce Apex class annotated with @RestResource that exposes custom server-side logic as a REST API endpoint. The custom endpoint that encapsulates complex Salesforce business logic — validation, related record creation, integration with Salesforce features — in a single API call rather than requiring multiple standard API calls from the integration client.

Calling Apex REST: the GET or POST /services/apexrest/{endpoint_path} request that calls the Apex REST service. The custom request and response format defined by the Apex class.

Integration Patterns

Operational system to Salesforce synchronisation. The most common Salesforce integration pattern — data created or updated in an operational system is synchronised to Salesforce. The e-commerce order that creates a Salesforce Opportunity. The support ticket that creates a Salesforce Case. The product shipment that updates the Salesforce Opportunity stage. The webhook from the operational system or scheduled sync job that propagates changes to Salesforce.

Salesforce to operational system synchronisation. Salesforce data that needs to flow to operational systems — the closed Opportunity that triggers account provisioning in a SaaS platform, the approved Quote that triggers order creation in the ERP, the resolved Case that triggers notification in the support system. Platform Events or Change Data Capture for real-time propagation, or polling for near-real-time.

Bidirectional contact and account synchronisation. Keeping customer master data consistent between Salesforce and other systems — CRM-to-ERP synchronisation, Salesforce-to-marketing-platform synchronisation. The external ID fields, the conflict resolution strategy, and the deduplication logic that prevent synchronisation loops and duplicate records.

Bulk data migration. The initial data load when connecting a new system to an existing Salesforce organisation — the Bulk API job that loads thousands or millions of records from the source system into Salesforce, respecting field mappings, handling validation errors, and producing a results report.

Technologies Used

  • C# / ASP.NET Core — Salesforce integration using the NetCoreForce library or direct HTTP with the Salesforce REST API
  • Python — Salesforce integration using the simple-salesforce library for REST API access and data pipeline development
  • TypeScript / Node.js — Salesforce integration using the jsforce library for Node.js applications
  • Java — Salesforce integration using the Salesforce Java SDK or direct REST API access for Java-based enterprise systems
  • JWT Bearer / OAuth 2.0 — Salesforce API authentication
  • REST / HTTP — Salesforce REST API communication
  • SOAP — Salesforce SOAP API and outbound message handling
  • CometD / Bayeux — Salesforce Streaming API and Platform Event subscription
  • Bulk API 2.0 — high-volume Salesforce data operations
  • SQL (PostgreSQL / MySQL) — synchronisation state, external ID mapping, event replay tracking
  • Redis — token caching, event deduplication, synchronisation job coordination
  • Hangfire / scheduled jobs — periodic synchronisation, bulk data operations
  • Docker — containerised integration service deployment
  • GitHub Actions — CI/CD pipeline for integration service deployment

Salesforce Integration Complexity

Salesforce integration complexity comes from several sources that simpler REST API integrations do not involve. The OAuth authentication with instance URL discovery rather than a fixed endpoint. The SOQL query language that differs from SQL in important ways. The relationship model between objects that requires understanding parent-child relationships for correct data navigation. The field-level security that may prevent reading or writing specific fields. The validation rules that enforce data quality and reject records that do not meet business rules. The governor limits that cap the number of API calls per 24-hour period and the Bulk API jobs per day.

Understanding these Salesforce-specific constraints and designing the integration to work within them — using the Composite API to reduce call volume, using Bulk API for large datasets, using the Streaming API rather than polling for real-time data, and designing the external ID strategy for upsert operations — is the difference between a Salesforce integration that works reliably in production and one that hits governor limits or produces inconsistent data.

Salesforce Connected to Your Business Systems

Salesforce integrations built to production standards — JWT Bearer authentication for server-to-server connectivity, SOQL queries optimised for the data access patterns required, Bulk API for high-volume data operations, Platform Events and Change Data Capture for real-time bidirectional synchronisation, composite operations that minimise API call volume, and the governor limit awareness that keeps integrations operating reliably within Salesforce's constraints.