LEARN SALESFORCE INTEGRATION

Learn Salesforce Integration: From REST to Real-Time Events

Goal: Deeply understand how to integrate external applications with the Salesforce platform. This guide focuses on the developer-centric, code-based methods of integration, covering authentication, the primary data APIs, and event-driven architecture.

Why Learn Salesforce Integration?

Salesforce is rarely an island. It’s the core CRM for many businesses, but its true power is unlocked when it communicates with other systems: ERPs, marketing automation platforms, custom web applications, and data warehouses. As a developer, knowing how to securely and efficiently move data in and out of Salesforce is a critical skill. You become the bridge that connects the entire business’s software ecosystem.

After completing these projects, you will:

Master Salesforce’s OAuth 2.0 authentication flows for any scenario.
Know when to use the REST, Bulk, and Streaming APIs.
Build robust, server-to-server integrations suitable for production.
Design and implement event-driven, real-time synchronization.
Understand how to work within Salesforce’s governor limits to build scalable solutions.

Core Concept Analysis

1. The Foundation: Connected Apps & OAuth 2.0

No external application can touch Salesforce without first being defined as a Connected App. This is a configuration within Salesforce that acts as the identity of your integration. It governs authentication and authorization.

Authentication is primarily handled via OAuth 2.0. You must understand two key flows:

Web Server Flow: For applications with a user interface. The user is redirected to Salesforce to log in and approve access. Your app receives an authorization code, which it exchanges for an access token.
JWT Bearer Flow: For server-to-server applications where no user is present. Your application uses a digital certificate and private key to sign a JSON Web Token (JWT) and sends it to Salesforce to get an access token directly. This is the standard for backend integrations.

2. The APIs: Right Tool for the Right Job

Salesforce provides a suite of APIs, each with a specific purpose.

┌────────────────────────────┐      ┌───────────────────────────┐      ┌────────────────────────────┐
│         REST API           │      │        Bulk API 2.0       │      │      Streaming API         │
│  (Synchronous, Small Payloads)   │      │ (Asynchronous, Large Data)  │      │ (Asynchronous, Real-Time)  │
└────────────────────────────┘      └───────────────────────────┘      └────────────────────────────┘
             │                                  │                                  │
             ▼                                  ▼                                  ▼
┌────────────────────────────┐      ┌───────────────────────────┐      ┌────────────────────────────┐
│ • Create/Read/Update/Delete│      │ • Load or extract millions  │      │ • Subscribe to data changes  │
│   a single record.         │      │   of records.             │      │   (PushTopic).             │
│ • Query data with SOQL.    │      │ • Asynchronous jobs.        │      │ • Publish/subscribe to custom│
│ • Good for UI interactions.│      │ • Handles CSV data.         │      │   events (Platform Events).│
└────────────────────────────┘      └───────────────────────────┘      └────────────────────────────┘

3. Governor Limits: The Rules of the Road

Salesforce is a multi-tenant platform, meaning your org shares resources with other customers. To ensure fairness and stability, Salesforce enforces Governor Limits. For integrations, the most important one is the 24-hour API Request Limit. Your integration design must be efficient to avoid hitting this limit. This is why choosing the right API (e.g., Bulk API for large jobs) is critical.

Environment Setup

This is not optional.

Get a Developer Org: Sign up for a free, permanent Developer Edition org at developer.salesforce.com/signup.
Install Tools:
- Postman or Insomnia for manual API testing.
- Python 3 and the requests, simple-salesforce, and pyjwt libraries.
- (Optional but recommended) Salesforce CLI (sfdx).

Project List

Project 1: Your First Access Token (No Code)

File: LEARN_SALESFORCE_INTEGRATION.md
Main Programming Language: N/A (GUI Tool)
Alternative Programming Languages: cURL
Coolness Level: Level 1: Pure Corporate Snoozefest
Business Potential: 1. The “Resume Gold”
Difficulty: Level 1: Beginner
Knowledge Area: Authentication / OAuth 2.0
Software or Tool: Postman/Insomnia, Salesforce UI
Main Book: Salesforce API Documentation.

What you’ll build: You will configure a “Connected App” in Salesforce and use Postman to manually perform the OAuth 2.0 Web Server Flow, successfully retrieving an access token.

Why it teaches the fundamentals: This project demystifies authentication. By performing each step manually—building the authorization URL, getting the code, exchanging it for a token—you will gain a concrete understanding of the OAuth “dance” before you ever try to automate it.

Core challenges you’ll face:

Creating a Connected App → maps to defining your application’s identity, permissions (scopes), and callback URL in Salesforce
Constructing the authorization URL → maps to understanding the required parameters like response_type, client_id, and redirect_uri
Exchanging the authorization code for a token → maps to making a POST request to the token endpoint with the correct parameters
Using the access token to make an API call → maps to passing the token as a Bearer token in the Authorization header

Key Concepts:

Connected Apps: Salesforce Docs - “Create a Connected App”
OAuth 2.0 Web Server Flow: Salesforce Docs - “OAuth 2.0 Web Server Flow”
Making API Requests: Postman Learning Center

Difficulty: Beginner Time estimate: A few hours Prerequisites: A Salesforce Developer Org, Postman/Insomnia installed.

Real world outcome: In Postman, you will make a successful GET request to the /services/data/vXX.X/ endpoint in your org and receive a JSON response listing the available APIs. You will have proven you can authenticate and communicate with Salesforce.

Implementation Hints:

In Salesforce Setup, find “App Manager” and create a “New Connected App”.
Enable OAuth Settings and add a Callback URL. For Postman, this can be a dummy URL like https://localhost/callback.
Note the Consumer Key (Client ID) and Consumer Secret (Client Secret).
In Postman, create a request. Under the “Authorization” tab, select “OAuth 2.0”. Fill in the URLs, Client ID, and Secret. Postman’s helper will guide you through the process of getting a token.

Learning milestones:

Your Connected App is created → You understand the entry point for all integrations.
You are redirected to the Salesforce login screen and approve access → The first leg of the OAuth flow is working.
Postman successfully receives an access token → You have completed the full authentication handshake.
You can use the token to successfully query the /userinfo endpoint → You have made your first authenticated API call.

Project 2: Server-to-Server Auth with JWT

File: LEARN_SALESFORCE_INTEGRATION.md
Main Programming Language: Python
Alternative Programming Languages: Node.js, Go, Java
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Authentication / API Security
Software or Tool: Python, pyjwt library, OpenSSL
Main Book: Salesforce API Documentation.

What you’ll build: A Python script that authenticates to Salesforce using the OAuth 2.0 JWT Bearer Flow. This script will run without any user interaction, generate a signed JWT, exchange it for an access token, and then fetch a list of Accounts using a SOQL query.

Why it teaches production auth: This is the standard, secure way for backend systems to talk to Salesforce. Mastering this flow is essential for building any automated integration. It teaches you about asymmetric cryptography (public/private keys) in a practical security context.

Core challenges you’ll face:

Generating a private key and self-signed certificate → maps to using openssl to create the necessary cryptographic materials
Configuring the Connected App for JWT → maps to uploading your digital certificate to the app and pre-authorizing a user profile
Constructing and signing the JWT payload → maps to using a library like pyjwt to create a token with the correct claims (iss, sub, aud, exp)
Exchanging the JWT for an access token → maps to making a single POST request to the token endpoint

Key Concepts:

OAuth 2.0 JWT Bearer Flow: Salesforce Docs - “OAuth 2.0 JWT Bearer Flow”
JWT Standard: jwt.io - Introduction to JSON Web Tokens
OpenSSL for Certificate Generation: OpenSSL Cookbook

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Project 1, basic Python, OpenSSL on your command line.

Real world outcome: You will run ./get_accounts.py on your command line. The script will authenticate, run a query, and print a list of Account names from your Salesforce org to the console, all without ever asking for a username, password, or requiring a web browser.

Implementation Hints:

Use openssl to generate a private key (server.key) and a certificate (server.crt).
Create a new Connected App. This time, check “Use digital signatures” and upload your server.crt file.
After saving, Manage the Connected App and “Edit Policies”. Under “OAuth Policies”, set “Permitted Users” to “Admin approved users are pre-authorized”.
Go to the Profile or Permission Set of the user you want the integration to run as, and explicitly assign this Connected App.
In Python, use the jwt library. The payload will include your client_id as the issuer (iss), the username as the subject (sub), and login.salesforce.com as the audience (aud).
Sign the JWT with your private key using the RS256 algorithm.
POST the signed JWT to Salesforce’s token endpoint. The response will contain your access token.

Learning milestones:

You successfully generate a key and certificate → You understand the cryptographic requirements.
The JWT is created and signed correctly → Your claims and signing logic are valid.
Salesforce accepts your JWT and returns an access token → You have mastered server-to-server authentication.
Your script fetches data using the token → The entire automated workflow is complete.

Project 3: A Bulk Data Loader

File: LEARN_SALESFORCE_INTEGRATION.md
Main Programming Language: Python
Alternative Programming Languages: Java, Shell (with curl and jq)
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Data Integration / Asynchronous APIs
Software or Tool: Python, Salesforce Bulk API 2.0
Main Book: Salesforce Bulk API 2.0 Developer Guide.

What you’ll build: A Python script that reads a large CSV file (e.g., 20,000 lead records) and uses the Bulk API 2.0 to load them into Salesforce. The script will create the job, upload the data, poll for the job’s completion status, and download and display any records that failed to process.

Why it teaches large data volume handling: This project forces you to think asynchronously and efficiently. Using the REST API for this task would be slow and would likely hit your daily API limit. The Bulk API is designed specifically for this use case and is a critical tool for any data migration or large-scale sync project.

Core challenges you’ll face:

Understanding the asynchronous workflow → maps to Create Job -> Upload Data -> Close Job -> Poll Status. This is different from the synchronous REST API.
Creating an ingestion job → maps to a POST request to /services/data/vXX.X/jobs/ingest specifying the object and operation
Uploading CSV data → maps to a PUT request with the raw CSV data to the endpoint provided when you created the job
Polling for job status and handling results → maps to periodically checking the job’s status and then downloading the successful and failed results files upon completion

Key Concepts:

Bulk API 2.0 Workflow: Salesforce Developer Guide - Bulk API 2.0
Governor Limits: Salesforce Docs - “API Request Limits and Allocations”
Asynchronous Programming Patterns: Understanding that you don’t get an immediate response.

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Project 2 (for authentication).

Real world outcome: You will run ./bulk_load.py leads.csv. The script will start, provide a job ID, and then print status updates (“Job Queued”, “In Progress”, …). Finally, it will print “Job Complete” and list any errors from the failedResults file. When you check Salesforce, you will see the 20,000 new lead records.

Implementation Hints:

Authenticate using the JWT flow from Project 2 to get a token.
POST to .../jobs/ingest with a JSON body like {"object": "Lead", "contentType": "CSV", "operation": "insert"}.
The response gives you a contentUrl. PUT your CSV data to that URL.
PATCH the job URL with {"state": "UploadComplete"}.
Now, periodically GET the job URL in a loop until state is JobComplete, Failed, or Aborted.
The final job info response will contain URLs to download successful and failed results.

Learning milestones:

A job is successfully created in Salesforce → You understand the first step of the async process.
Your CSV data is successfully uploaded → You can send data to the job.
You can poll the job and detect its completion → You’ve implemented the asynchronous monitoring loop.
You successfully load thousands of records far more efficiently than the REST API could → You understand the primary use case for the Bulk API.

Project 4: Real-Time Notifications with Streaming API

File: LEARN_SALESFORCE_INTEGRATION.md
Main Programming Language: Python
Alternative Programming Languages: Node.js, Java
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 3: Advanced
Knowledge Area: Event-Driven Architecture / Streaming
Software or Tool: Python (requests library), Salesforce Streaming API
Main Book: Salesforce Streaming API Developer Guide.

What you’ll build: A long-running Python script that subscribes to a PushTopic in Salesforce. The PushTopic will be configured to send a notification whenever an Opportunity’s StageName is updated to ‘Closed Won’. Your script will listen for these events in near real-time and print a “Cha-ching! We won a deal!” message to the console.

Why it teaches event-driven architecture: This project flips the integration model. Instead of your application constantly polling Salesforce for changes (“Are we there yet?”), Salesforce will tell your application when something interesting happens. This is vastly more efficient and scalable.

Core challenges you’ll face:

Understanding the CometD protocol → maps to Salesforce’s streaming uses the Bayeux/CometD protocol, which requires a handshake and a persistent connection
Creating a PushTopic via SOQL → maps to defining the query that determines which events get published
Subscribing to a channel → maps to making a series of POST requests to /cometd to handshake, connect, and subscribe
Handling a long-lived connection → maps to keeping the connection alive and parsing the stream of incoming events

Key Concepts:

Streaming API Concepts: Salesforce Developer Guide - Streaming API
PushTopics: Salesforce Developer Guide - PushTopics
CometD Protocol: CometD Project Documentation

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Project 2, understanding of HTTP and basic async concepts.

Real world outcome: Your Python script will be running and seemingly doing nothing. You will then go into the Salesforce UI, find an Opportunity record, and change its Stage to ‘Closed Won’. Almost instantly, a message will appear in your script’s console with the details of the won Opportunity.

Implementation Hints:

This is more complex than a simple REST call. You might want to use a library that handles CometD, but doing it manually with requests is a better learning experience.
The Dance:
1. Authenticate to get a token and your instance URL.
2. POST to /cometd/45.0/handshake to start the connection. Note the clientId.
3. POST to /cometd/45.0/connect with your clientId to open the long-polling request. This request will hang open until an event arrives.
4. In parallel, POST to /cometd/45.0/subscribe with your clientId and subscription: "/topic/MyDeals".
Use the Salesforce UI (Developer Console) or Apex to create the PushTopic: PushTopic pushTopic = new PushTopic(Name='MyDeals', Query='SELECT Id, Name, Amount FROM Opportunity WHERE StageName = \'Closed Won\'', ApiVersion=55.0); insert pushTopic;.

Learning milestones:

You successfully handshake and subscribe to the CometD endpoint → You’ve established a streaming connection.
Your PushTopic is created and active → You’ve defined what data changes you care about.
Updating a record in the UI sends a message to your script → The event publishing is working.
Your script can parse the incoming event and extract the data → You have a working, real-time, event-driven integration.

Project 5: A Two-Way Synchronization Service

File: LEARN_SALESFORCE_INTEGRATION.md
Main Programming Language: Python
Alternative Programming Languages: Go, Java
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 5. The “Industry Disruptor”
Difficulty: Level 4: Expert
Knowledge Area: Systems Integration / Data Synchronization
Software or Tool: Python, SQLite, Salesforce REST/Bulk/Streaming APIs
Main Book: “Enterprise Integration Patterns” by Hohpe & Woolf.

What you’ll build: A capstone project: a service that performs a two-way synchronization between “Product” records in a local SQLite database and the “Product2” object in Salesforce.

Outbound Sync (Local -> Salesforce): A script runs periodically, finds new/updated products in the local DB, and uses the REST/Composite API to upsert them into Salesforce.
Inbound Sync (Salesforce -> Local): A long-running process subscribes to a PushTopic/Platform Event to receive real-time updates for Products from Salesforce and writes them to the local SQLite DB.
Initial Load: A one-time script uses the Bulk API to perform the initial population of the local DB from Salesforce.

Why it teaches a complete pattern: This project combines everything you’ve learned. It’s a microcosm of a real-world, robust integration. You have to handle initial data loads, ongoing changes in both directions, and choose the right API for each task to manage performance and governor limits.

Core challenges you’ll face:

Designing a sync strategy → maps to how do you avoid infinite loops? How do you track last-sync timestamps? How do you handle conflicts?
Combining multiple APIs → maps to using Bulk API for the initial load, REST for small real-time updates, and Streaming for inbound changes
Building a stateful service → maps to your sync service needs to store metadata, like the timestamp of its last successful run
Error handling and resilience → maps to what happens if an API call fails? How does the service recover and retry without losing data?

Key Concepts:

Integration Patterns: “Enterprise Integration Patterns” (e.g., Synchronization, Polling, Publish-Subscribe).
Idempotency: Ensuring that making the same API call multiple times has the same effect as making it once. upsert helps with this.
State Management: Storing sync state outside of the core application logic.

Difficulty: Expert Time estimate: 1 month+ Prerequisites: All previous projects.

Real world outcome: You will have two processes running. You can create a new product in your local SQLite database, and within a minute, it will appear in Salesforce. You can then change that product’s price in the Salesforce UI, and you will instantly see the change reflected back in your local SQLite database.

Implementation Hints:

Use a LastModifiedDate timestamp column in your local DB and query against it to find recent changes to push to Salesforce.
Use an external ID field in Salesforce (External_ID__c) to store the primary key from your local database. Use this external ID for upsert operations.
For the inbound sync, use a PushTopic that monitors changes to the Product2 object. When an event is received, upsert it into your local SQLite DB based on the External_ID__c.
Structure your code carefully. Have separate modules for Salesforce authentication, each API client, and the core sync logic.

Learning milestones:

The Bulk API script successfully performs the initial data load → Your large-data-volume process works.
Changes made locally are reflected in Salesforce → Your outbound sync is working.
Changes made in Salesforce are reflected locally → Your inbound, event-driven sync is working.
The entire system can run for an extended period, handling changes in both directions without losing data or hitting major errors → You have built a true, two-way synchronization service.

Summary