Study guide

Study guide for chapter 9 of the Integration Architect course. Read the eight 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 the other direction: Salesforce calling out. It carries two Build Solution objectives: API design with Salesforce as the consumer, and choosing an option for outbound calls. The rule that catches most people is in module 5: call, then write.

For the Exam

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

Leaving Salesforce (BLD-2)

I know Salesforce blocks every outbound call until you approve the way out, with a named credential. (Salesforce Won’t Let You Leave Until You Approve It)
I know the three things you need to reach any system: the location, the credentials, and the functions. (Three Things You Need)
I know the same news can leave Salesforce more than one way, and choose by the requirement. (Choosing a Way Out)

The six lines of a callout (BLD-1)

I know the six lines: Http, HttpRequest with setEndpoint and setMethod, Http.send, and HttpResponse with getStatusCode and getBody. (The Six Lines)
I know the endpoint is approved with a named credential (callout:), or the older remote site setting. (The Six Lines)
I know a GET has no body, and the default timeout is 10 seconds, up to 120. (What Else Goes on the Request)
I know Salesforce can still call SOAP, by generating Apex from the other system’s WSDL. (What About SOAP?)

Dealing with the answer (BLD-1)

I check the status code before I read the body. (Status First)
I check the answer’s Content-Type before I parse, because the contract and the answer don’t always agree. (Then the Format)
I can pick the right point on the parsing spectrum, from one line into a matching class to a full parser. (Then the Parse)
I take full answers out of the debug log before production. (Don’t Log What You Shouldn’t)

Speed limits (BLD-2)

I know the per-transaction limits: 100 callouts, 120 seconds for all of them together, and heap of 10 MB synchronous or 25 MB asynchronous, which fails with an uncatchable error. (The Limits on One Transaction)
I know the long-running limit: synchronous Apex over 5 seconds, 10 to 50 at once by licences, and that time spent waiting on a callout doesn’t count. (The Red Transactions)
I can tell this limit from chapter 8’s inbound one: 25 calls of 20 seconds or more coming in. (Two Long-Running Limits, Not One)

Where a callout can run (BLD-2)

I know you can’t write and then call out in the same transaction; you can call, then write. (Call, Then Write)
I know a synchronous callout with a person waiting comes from a Lightning web component or a screen flow, not a trigger. (From a Page That Waits)
I hand a callout from a save to asynchronous Apex, such as @future(callout=true) or a Queueable. (From a Save: Hand It Off)
I know Batch Apex can call out with Database.AllowsCallouts. (From a Job)
I know that at volume, Salesforce’s architects say to use platform events and middleware instead of callouts from asynchronous Apex. (Or Don’t Call at All)
I can choose between clicks (External Services, Flow HTTP callouts) and Apex. (Clicks or Code)

Callbacks and outbound messages (BLD-2)

I know outbound messages are SOAP, sent from a flow through Salesforce’s queue to a listener you build from its WSDL, which must acknowledge each one. (How an Outbound Message Works)
I know what they can’t promise: up to 100 notifications per message, retried for 24 hours, possibly out of order or more than once. (What It Can’t Promise)
I know they carry the changed record’s fields only, not its children, and that the listener calls back with OAuth: session IDs are no longer sent. (Only the Record That Changed, Call Back With Your Own Key)
I know when I’d still choose one today: rarely, mostly when I inherit it. (When You’d Choose It Today)

Testing callouts (BLD-1)

I know tests can’t call out, and a mock (Test.setMock) plays the other system. (A Mock Plays the Other System)
I test the failures on purpose, not only the happy path. (Make It Fail on Purpose)
I keep inserts outside Test.startTest() and Test.stopTest(), so call, then write holds in tests too. (Call, Then Write, in Tests Too)

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.

Every way out goes through a gate you approved. Named credentials, not addresses in code.
Status first, then the format, then the parse.
Count before you build: the size of the answer, the calls per transaction, the peak.
Set the timeout from the other system’s real speed, and decide what happens when it’s hit.
A person waits only when the business needs the answer now. Everything else goes later.
Let an AI write the classes, and a person check them against this chapter.
A mock can’t catch a broken named credential. Test against the real thing before go-live.

Words to Know

Term	In one line
Callout	Salesforce calling another system
Named credential	The approved way out: where, and how to sign in, kept out of the code
Remote site setting	The older way to approve an address
Status code	The first thing to read in any answer
Heap	Everything a transaction holds in memory, the answer included
Red transaction	Synchronous Apex running more than 5 seconds
Call, then write	The rule: no callout after a write in the same transaction
`@future(callout=true)`	An asynchronous method allowed to call out
Queueable	Asynchronous Apex that can be chained and can call out
External Services	A callout built in clicks from the other system’s description
Outbound message	The legacy SOAP message from a flow, retried for 24 hours
Mock	A fake answer that plays the other system in a test

Check Yourself

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

1. A trigger updates the delivery, then calls Redrock to say it's done. In testing it fails with "uncommitted work pending". Why, and what's the fix?

A callout can’t follow a write in the same transaction. Hand the callout to asynchronous Apex, such as a Queueable, so it runs after the save commits. Reread Call, Then Write.

2. A rep must know the customer's balance before saving an order. Where does the callout run?

From a page that waits: a Lightning web component or a screen flow calls before the save, and stops the rep with a message if needed. A trigger runs after the save starts, too late to call out. Reread From a Page That Waits.

3. The service usually answers in 2 seconds. What timeout do you set, and why not the maximum?

Set it from the service’s real speed, with a margin, not the default 10 or the maximum 120 seconds, and decide what happens when it’s hit. Two minutes is what Salesforce allows, not what a person will wait. Reread Designing for the Limits.

4. A callout returns a large list and the transaction dies with an error your try and catch can't stop. What happened?

The heap limit: 10 MB synchronous, 25 MB asynchronous, and going over is uncatchable. Ask for less, page through it, or move the data another way. Reread The Limits on One Transaction.

5. The contract says JSON. Your parser fails on the first call. What do you check?

The status code first, then the Content-Type header: the answer may be XML, or an error page. Reread Then the Format.

6. You inherit an outbound message whose listener calls back using the session ID in the message. It stopped working. Why?

Salesforce no longer sends session IDs in outbound messages. The listener must call back with its own OAuth token, as its own integration user. Reread Call Back With Your Own Key.

7. Thousands of status updates an hour need to reach three partners. A Queueable per update?

At that volume, Salesforce’s architects say publish platform events and let middleware deliver them, because asynchronous threads are finite. Reread Or Don’t Call at All.

8. Every callout test passes, and the first production call fails. What could the tests not see?

A mock never goes through the named credential, never signs in, and never meets the real system. Test the real connection in a sandbox before go-live. Reread What a Mock Can’t Catch.

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.
Apex Developer Guide, Callout Limits and Limitations (opens in a new tab): the limits this chapter uses.