Study guide

Study guide for chapter 8 of the Integration Architect course. Read the seven modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter is about the doors other systems use to call Salesforce. It carries two objectives from the exam’s biggest sections: specifying the right Salesforce API (Design Integration Solutions) and API design with Salesforce as the provider (Build Solution). Know which door fits which job, what each one costs, and who is behind every call.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

All the locked doors (DES-4)

I know Salesforce has well over 100 doors, and that the useful skill is grouping them by what the caller is doing, not remembering the count. (How Many Doors?)
I know a client program first gets a token from the token server, through an External Client App and its integration user, then carries the token on every call. (The Doors a Client Uses)
I can ask an org which versions and doors it serves (/services/data/), and know a version keeps its promise until it’s retired. (Ask the Org Which Doors It Has)
I know the API Total Usage event log is how to find callers still on an old version. (Who’s Still Using an Old Door?)

REST first (DES-4, BLD-1)

I can say why REST is the first door: the same port as web pages, small answers, and every language already speaks it; SOAP when you need it. (Why REST First)
I pin a version for production integrations, and keep latest for scripts and internal tools. (Pin the Version)
I know a query returns up to 2,000 records a page, and the caller follows the next page. (Query: Ask for a List)
I use upsert by an external ID when the caller doesn’t have Salesforce’s ID. (Create, Update and Upsert)
I know an API write isn’t a back door: triggers, flows, validation rules, permissions and sharing all run. (Your Automations Still Run)
I know the “updated” and “deleted” calls look back 30 days at most, and return IDs, not records. (What Changed Since?)

Many in one call (DES-4, BLD-1)

sObject Collections: up to 200 records to write, 2,000 to read, the whole request one call. (sObject Collections)
sObject Tree: new parents with their children, up to 200 records and five levels. (sObject Tree)
Composite: up to 25 subrequests that pass values along, all or none optional. (Composite)
Composite graph: up to 500 subrequests per graph, each graph all or nothing. (Composite Graph)
I know when composite beats bulk: parents and children together, many times a minute; thousands of records of one object go to the Bulk API; Salesforce’s line is about 2,000 records. (Which One?)

GraphQL and the UI API (DES-4)

I know GraphQL lets the client choose the fields, at one address, and describes itself. (GraphQL: The Client Decides)
I know one GraphQL request isn’t one API call: each subquery counts, and the default page is 10 records. (What GraphQL Doesn’t Change)
I know the UI API returns a record the way Salesforce’s own screen shows it, layout and all. (The UI API: Give Me the Screen)

Your own door (BLD-1)

I can choose between the standard API (the caller knows every object, field and rule) and a custom Apex REST door (the caller knows only the contract). (How to Choose)
I keep sObjects out of the contract: the request and response are their own small classes. (The Contract Is Its Own Classes)
I version my own door in its address, and know Apex REST calls still count against the API limits. (What an Architect Checks on Every Door)
I answer errors with Problem Details (RFC 9457) and slow callers with 429 and Retry-After. (Answer Errors the Web’s Way, Tell Callers When to Come Back)

When someone calls you back (BLD-1)

I know Salesforce has no built-in place to receive a webhook, and the first choice is to let the integration layer receive it and call in. (Three Ways In)
I can name the four checks every receiver makes, starting with the signature. (Four Things Every Receiver Checks)

Who’s at the door (BLD-1)

I give every caller its own integration user, with only the access its job needs. (Every Call Runs as Someone)
I know the daily API allowance belongs to the org, not the user. (One Allowance for the Whole Org)
I know the long-call limit: 25 requests of 20 seconds or more at once in production, then REQUEST_LIMIT_EXCEEDED. (The Limit That Catches People)
I know where to watch the meter: the Sforce-Limit-Info header, /limits, System Overview and API Usage Notifications. (Watching the Meter)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

Write down every caller’s door and version, and find the ones nobody wrote down.
Pin the version in production. Know when each one retires.
Ask for only what you need, in fields and in records.
Decide what runs when an integration writes, and test the rules written for people.
Choose standard or your own door by who should know your inner workings.
Let the integration layer receive what the internet sends.
One integration, one user, one budget line.

Words to Know

Term	In one line
Door	One endpoint a caller can use to reach Salesforce
Integration user	The user an integration runs as, with only the access its job needs
Pinned version	A fixed API version in the address, so the contract doesn’t change
Upsert	Insert or update in one call, matched by an external ID
sObject Collections	Many records of one kind, in one call
sObject Tree	New parents with their children, in one call
Composite	Up to 25 requests in one call, passing values along
Composite graph	Large sets of related requests, each set all or nothing
GraphQL	One address; the client chooses the fields
UI API	A record as Salesforce’s own screen shows it
Apex REST	Your own door, built in Apex, with your own contract
Problem Details	The web’s standard error format (RFC 9457)
Webhook	An HTTP POST another system sends when something happens
API allowance	The org’s shared count of calls in 24 hours

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. A partner sends its own order reference with every update, and doesn't know Salesforce's IDs. What call should it make?

An upsert by an external ID: store the partner’s reference in a unique External ID field, and the same call inserts or updates. Reread Create, Update and Upsert.

2. A manifest arrives with 40 deliveries, each with line items, many times an hour. Bulk API or composite?

Composite: parents and children together, arriving often, in one call that counts once. The Bulk API is for thousands of records of one object. A composite graph makes each manifest all or nothing. Reread Which One?

3. A mobile app needs five fields from three objects over a slow connection. Which door?

GraphQL: the client asks for exactly those fields in one request. Remember each subquery still counts against the limits, and pages default to 10 records. Reread GraphQL and the UI API.

4. The other team keeps breaking every time you rename a field. What would you change?

Give them your own door: a custom Apex REST service with a contract of its own classes, so your Apex absorbs the change and the contract stays the same. Reread How to Choose.

5. An SMS provider wants to send delivery reports to Salesforce by webhook. Where should they land?

On the integration layer, which checks the signature and then calls Salesforce through a normal door with a normal token. Salesforce has no built-in front desk for webhooks. Reread Three Ways In.

6. Three partners each get 30,000 calls a day "of their own". Is that right?

No. The allowance belongs to the org and is shared by every caller. Budget each integration’s share, and watch the meter. Reread One Allowance for the Whole Org.

7. At 4 p.m. calls start failing with `REQUEST_LIMIT_EXCEEDED`, though the daily allowance is barely used. What's happening?

Too many long calls at once: 25 requests of 20 seconds or more in production. Make the calls shorter, or move the heavy work off the call. Reread The Limit That Catches People.

8. Salesforce warns that an API version you think nobody uses is about to retire. How do you find out who still calls it?

The API Total Usage event log: one line per request, with its version and the user who made it. Reread Who’s Still Using an Old Door?

Explore

Salesforce Certified Platform Integration Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam.
Salesforce Help, Which API Do I Use? (opens in a new tab): Salesforce’s own short map of its APIs.