Salesforce API Landscape

Salesforce exposes dozens of APIs, each built for specific use cases. Choosing the wrong one is a common CTA pitfall. This page covers every API that matters for the exam: decision criteria, volume thresholds, and rate limits.

---

API Decision Matrix

API	Protocol	Format	Best For	Volume	Direction
REST API	REST	JSON/XML	CRUD operations, modern integrations	Low-medium	Bidirectional
SOAP API	SOAP	XML	Legacy systems, full metadata access	Low-medium	Bidirectional
Bulk API 2.0	REST	CSV/JSON	Large data loads (thousands+)	High	Bidirectional
Composite API	REST	JSON	Multi-step operations, reducing roundtrips	Low-medium	Inbound
Streaming API	Bayeux/CometD	JSON	Real-time notifications (legacy)	Event-based	Outbound
Pub/Sub API	gRPC	Avro/Binary	High-throughput event streaming	Event-based	Bidirectional
Platform Events API	REST	JSON	Custom business events	Event-based	Bidirectional
Change Data Capture	Pub/Sub	Avro	Data change notifications	Event-based	Outbound
GraphQL API	GraphQL	JSON	Flexible queries, mobile optimization	Low-medium	Bidirectional
Metadata API	SOAP/REST	XML/JSON	Deployment, org configuration	N/A	Bidirectional
Tooling API	REST/SOAP	JSON/XML	Developer tools, IDE integration	N/A	Bidirectional
Analytics API	REST	JSON	CRM Analytics (Tableau CRM) data	Reports/dashboards	Bidirectional
Connect API (Chatter)	REST	JSON	Social features, feeds, communities	Low	Bidirectional
Apex REST/SOAP	REST/SOAP	JSON/XML	Custom business logic endpoints	Low-medium	Inbound

---

REST API

The most commonly used Salesforce API. JSON-based, lightweight, suitable for most CRUD operations.

Key Characteristics

• Standard HTTP methods (GET, POST, PATCH, DELETE)
• JSON or XML payloads
• Versioned endpoints (e.g., /services/data/v66.0/sobjects/Account/)
• Supports SOQL and SOSL queries
• Named Credentials for authentication

When to Use

• Modern integrations with JSON-capable systems
• Single-record or small-batch CRUD operations
• Mobile and web application backends
• Any integration where simplicity is valued

Rate Limits

Edition	API Requests per 24 Hours
Enterprise	100,000 (base) + 1,000 per Salesforce license
Unlimited	100,000 (base) + 5,000 per Salesforce license
Per user addition (other licenses)	200 per Platform, Force.com, or other license type

Concurrent call limit

All API types share a concurrent long-running call limit of 25 (for total org, not per user). Calls running longer than 20 seconds count against this limit. This is one of the most commonly overlooked limits in CTA scenarios.

When NOT to Use

• Volumes exceeding a few thousand records per transaction (use Bulk API)
• When you need to subscribe to data changes (use Streaming/Pub/Sub)
• When the consumer is a legacy SOAP-only system (use SOAP API)

---

SOAP API

XML-based API using WSDL contracts. Same data access as REST, but with stronger typing and full metadata access.

Key Characteristics

• WSDL-based service definitions
• Enterprise WSDL (strongly typed, org-specific) and Partner WSDL (loosely typed, generic)
• Full metadata access capabilities
• Session-based authentication

When to Use

• Legacy systems that require WSDL contracts
• When you need the Partner WSDL for ISV/multi-org tools
• Metadata operations (though Metadata API is more focused)
• When strong typing and contract-first design are required

When NOT to Use

• Modern integrations (REST is simpler and lighter)
• High-volume operations (use Bulk API)
• Mobile applications (XML payload overhead)

---

Bulk API 2.0

Purpose-built for loading, querying, and deleting large datasets. Uses a job-based asynchronous pattern.

Key Characteristics

• Asynchronous, job-based processing
• CSV or JSON input/output
• Supports insert, update, upsert, delete, and hard delete
• Automatic batching by the platform
• Query all records with SOQL (Bulk Query)

How It Works

Figure 1. Bulk API 2.0 uses a job-based async lifecycle: create, upload, close, poll, retrieve results. Partial failures are normal, so retrieve success and failure result files separately and resubmit only failed records.

Volume Guidance

Scenario	Recommendation
< 200 records	REST API (single or Composite)
200 - 2,000 records	REST API Composite or Bulk API
2,000 - 100,000 records	Bulk API 2.0 (serial mode)
100,000 - 10M records	Bulk API 2.0 (parallel mode)
10M+ records	Bulk API 2.0 + partitioned jobs + off-peak
Query large datasets	Bulk Query (Bulk API 2.0 query operation)

Serial vs Parallel Processing

Mode	Behavior	When to Use
Serial	Records processed in order, one batch at a time	Lock contention risk, parent-child relationships
Parallel	Multiple batches processed concurrently	Independent records, maximum throughput

Limits

Limit	Value
Max records per 24-hour period	100 million
Max record size	10 MB per record
Max file size per upload	100 MB (recommended)
Query result size	1 GB per query

Serial mode for parent-child

When loading data with parent-child relationships (e.g., Accounts then Contacts), use serial mode or separate jobs with ordering. Parallel mode can cause lock contention and “UNABLE_TO_LOCK_ROW” errors. This is a frequent CTA scenario trap.

---

Composite API

Packs multiple API operations into a single HTTP request, cutting round trips. Three variants serve different needs.

Variants

Variant	Max Subrequests	Dependencies	Use Case
Composite	25	Yes (reference previous results)	Multi-step operations with dependencies
Composite Batch	25	No (all independent)	Multiple independent operations
sObject Tree	200 records	Parent-child	Creating record trees (Account + Contacts)
sObject Collections	200 records	No	Bulk CRUD on same object type

Composite Request Flow

Figure 2. Composite API reduces five separate API calls to one, using reference IDs to chain dependent operations. Each subrequest can reference the output of a prior one, enabling parent-child record creation in a single round trip.

Composite Subrequest Processing (Internal Flow)

How Salesforce processes subrequests internally explains allOrNone behavior and reference ID resolution, both commonly tested at the CTA board.

Figure 3. The allOrNone flag determines whether a subrequest failure rolls back all prior work or allows partial success. Reference IDs resolve sequentially, so a failed subrequest breaks all downstream references that depend on it.

Behavior	allOrNone = true	allOrNone = false
Transaction scope	All subrequests share one transaction	Failed subrequests do not roll back previous successful ones, but all subrequests execute within the same request context (not separate database transactions)
On failure	Entire request rolls back	Only failed subrequest rolls back
Reference IDs	Resolved sequentially	Resolved sequentially (but failed refs cause downstream failures)
Use case	Parent-child record creation where all must succeed	Independent operations where partial success is acceptable
Governor limits	Shared across all subrequests	Shared across all subrequests

Reference ID dependency chains

If subrequest 2 references the ID from subrequest 1, and subrequest 1 fails with allOrNone=false, subrequest 2 will also fail because the reference cannot be resolved. Design your subrequest order carefully and always place dependent operations after their prerequisites.

When to Use

• Creating related records in a single transaction
• Reducing API call consumption (1 call instead of 25)
• Mobile apps where network round trips are expensive
• When operations have dependencies on each other

---

Composite Graph API

Extends the standard Composite API from 25 to 500 subrequests, organized into multiple independent graphs within a single HTTP request. Available in API v50.0+.

Composite API vs Composite Graph API

Capability	Composite API	Composite Graph API
Max subrequests	25	500
Grouping	Single linear sequence	Multiple independent graphs
Transaction scope	One transaction (with allOrNone)	Each graph is its own transaction
Cross-graph references	N/A	Not supported - references only within a graph
Use case	Small multi-step operations	Complex record trees, data loading with parent-child hierarchies

Graph Structure and Transaction Behavior

Each graph is always transactional: all subrequests in a graph succeed or all fail (allOrNone is implicitly true per graph). The parent request is not transactional as a whole. If Graph A succeeds and Graph B fails, Graph A’s changes persist. Partial success only happens across graphs, never within a single graph.

Figure 4. Composite Graph API groups up to 500 subrequests into independent transactional graphs within a single HTTP call. If Graph 2 fails, Graph 1 changes persist. Failure isolation is per-graph, not per-request.

When to Use Composite Graph API

• Loading record trees where 25 subrequests is insufficient (e.g., Account + Contacts + Opportunities + line items in one call)
• Batch operations that need transactional grouping by logical entity (each graph = one business entity)
• Reducing API call consumption in high-volume synchronous integrations
• When different record groups need independent transaction boundaries within the same request

When NOT to Use

• Under 25 subrequests - standard Composite API is simpler
• When you need cross-graph references (use a single graph or chain requests)
• Bulk data loads of thousands of records - Bulk API 2.0 is more appropriate

CTA Exam Relevance

Composite Graph API is the answer when a scenario needs complex record trees in a single synchronous call and 25 subrequests is not enough. The key architectural point: each graph is its own transaction. This isolates failures to one business entity without rolling back unrelated records in other graphs.

---

Pub/Sub API (gRPC)

The modern, high-performance event streaming API built on gRPC with Avro-encoded events. Replaces the legacy Streaming API.

Key Characteristics

• gRPC-based bidirectional streaming
• Avro binary encoding (compact, schema-enforced)
• Subscribe to Platform Events, Change Data Capture, and custom channels
• Publish and subscribe capabilities
• Supports managed subscriptions with server-side cursor tracking

Architecture

Figure 5. Pub/Sub API uses gRPC over HTTP/2 with Avro binary encoding, enabling high-throughput bidirectional streaming. Multiple independent subscribers receive the same events without any subscriber affecting another’s delivery.

When to Use

• High-throughput event consumption from external systems
• When you need managed subscriptions (server tracks position)
• Modern event-driven architectures
• Replacing legacy CometD/Bayeux Streaming API

When NOT to Use

• Simple, low-volume polling (REST API query is simpler)
• If gRPC is not supported in the client environment
• Batch data synchronization (use Bulk API)

---

Streaming API (Legacy)

CometD/Bayeux long-polling protocol for near-real-time notifications. Being superseded by Pub/Sub API.

Channels

Channel Type	Purpose	Example
PushTopic	SOQL-based record change notifications	New high-value Opportunities
Generic Streaming	Custom event broadcasting	Application-specific events
Platform Events	Custom business events	OrderPlaced, PaymentReceived
Change Data Capture	Standard/custom object changes	Any field change on Account

PushTopic and Generic Streaming retiring Summer 2027

PushTopics and Generic Streaming Events are deprecated (since Spring ‘19) and retiring in Summer 2027. No new features are added. For new implementations, use Pub/Sub API with Platform Events or Change Data Capture. The CTA board may still ask about Streaming API for legacy scenarios — understand the pattern but always recommend the modern replacements for new designs.

---

GraphQL API

Consumers request exactly the data they need in a single query, avoiding over-fetching and under-fetching.

Key Characteristics

• Single endpoint: /services/data/v66.0/graphql
• Queries (all versions) and mutations (beta v59.0-v65.0, GA in API v66.0 / Spring ‘26)
• Supports SOQL-like filtering and relationship traversal
• Ideal for mobile and bandwidth-constrained clients

When to Use

• Mobile applications needing optimized payloads
• Complex queries spanning multiple related objects
• When consumers need flexible, self-service data access
• Reducing the number of API calls for related data

When NOT to Use

• Bulk data operations
• When consumers are WSDL-based legacy systems

---

Metadata API & Tooling API

Metadata API

• Deploy and retrieve metadata (custom objects, fields, layouts, etc.)
• Used by Salesforce CLI, VS Code extensions, CI/CD pipelines
• SOAP-based (with REST Metadata API for some operations)
• Not for data operations - for org configuration only

Tooling API

• REST and SOAP access to metadata for developer tooling
• Supports SOQL against metadata types (ApexClass, ApexTrigger, etc.)
• Used for: code compilation, debug logs, test execution, code coverage
• Lighter-weight than Metadata API for specific use cases

---

API Selection Decision Flowchart

Figure 6. API selection depends on operation type, volume, protocol constraints, and whether the use case is event-driven. The most common mistakes are using REST API for bulk volumes (use Bulk API 2.0) and polling for changes (use CDC or Platform Events).

---

Rate Limits Summary

Limit Type	Value	Applies To
Daily API requests	100K base + per-user (EE: 1,000/user, UE: 5,000/user)	REST, SOAP, Composite, Bulk
Concurrent API requests (long-running)	25	All APIs
Bulk API 2.0 daily records	100 million	Bulk API 2.0
Streaming API concurrent clients	2,000	Streaming/Pub/Sub
Platform Events published per hour	Varies by allocation	Platform Events
Composite subrequests	25 per request	Composite API
sObject Collections	200 records per request	Collections API
API request timeout	120 seconds	All synchronous APIs
Callout timeout (Apex)	Default 10s per callout, configurable up to 120s; 120s cumulative per transaction	Apex HTTP callouts

API limit exhaustion

Running out of daily API calls is a production emergency. Always design with API limit budgeting: estimate daily call volume, compare to allocation, and build in headroom. If the math does not work, switch to Bulk API, Composite API, or change the pattern to cut call volume.

---

API Authentication

Every API call requires authentication. The table below maps each OAuth flow to its integration use case. For the full flow decision tree, sequence diagrams, and security comparison, see Identity & SSO - OAuth 2.0 Flows.

OAuth Flow	Integration Use Case	Involves User?
Web Server Flow	User-facing applications with backend	Yes
JWT Bearer Flow	Server-to-server, automated integrations	No (service account)
Device Flow	Input-constrained devices, CLI tools	Yes (out-of-band)
Client Credentials Flow	Machine-to-machine (no user context)	No

Named Credentials

Always recommend Named Credentials for Salesforce-initiated callouts. They handle token management, refresh, and credential storage securely. Hardcoding credentials or storing tokens in custom settings is an anti-pattern the board will challenge.

---

CTA Scenario Tips

• Count your API calls: For every integration, estimate daily API consumption and compare against limits
• Composite for efficiency: If a process requires 5 API calls, ask whether Composite can reduce it to 1
• Bulk for volume: Any time data volume exceeds a few thousand records, the answer is almost always Bulk API 2.0
• Pub/Sub for events: For real-time event-driven architectures, Pub/Sub API is the modern choice
• GraphQL for mobile: When a mobile or SPA frontend needs flexible data, GraphQL reduces over-fetching
• Named Credentials always: There is no acceptable reason to hardcode credentials in a CTA scenario

---

Related Topics

• Large Data Volumes: Bulk API 2.0 selection and volume thresholds tie directly to LDV considerations
• Shield & Encryption: API access to encrypted fields; Shield Platform Encryption affects API behavior
• Platform Capabilities: API limits depend on edition, license type, and org-level platform limits

---

Sources

• Salesforce API Overview (Official)
• Salesforce REST API Developer Guide
• Composite API Documentation
• Composite Request Body Reference
• Bulk API 2.0 Developer Guide
• Pub/Sub API Developer Guide
• Salesforce API Limits
• Trailhead: API Basics
• Composite Graph API (REST API Developer Guide)
• Composite Graph Limits
• Salesforce Architect: API Strategy