Salesforce as an API Provider

Chapter 8 of Integration Architect, Part 2: Designing Integrations That Work (Design), and the first chapter of Part 2. Previous: Integration Patterns · Next: Salesforce as an API Consumer.

Part 1 ended with a pattern for every arrow. Part 2 picks the mechanism behind each one, and this chapter starts with the arrows that point in: other systems calling Salesforce.

Think of Salesforce as a building with locked doors. You’re a process outside it, and Salesforce won’t come out and find you. You have to reach in. You have to start the connection. Counted one endpoint at a time, there are well over 100 doors. This chapter is about which one to use, what each one costs, and who’s standing at it.

Steve Trucking runs through every module: Redrock’s manifests coming in, the crews’ app, a Retail Partner’s own screens, and the SMS provider calling back.

The ideas in this chapter

Every way in is a door, and some have nobody signing in. People, web forms, email and programs each come in a different way. Public forms and email need a guard, and Salesforce is moving towards every capability behind a door, for programs and AI agents alike.
Pin the version, and know who still calls an old one. A pinned version keeps its promise; the free API Total Usage log tells you who’s still on a version that’s about to retire.
REST first, and upsert by the caller’s key. Query, describe, one record, create, update. Read every page, ask only for what you need, and let callers upsert with their own key so a retry never makes a duplicate. Your automations still run on every call.
Records that belong together go in one call. Collections, tree, composite and composite graph: one call against the allowance, and an all-or-nothing line drawn where it belongs.
The client decides the shape, or the org does. GraphQL returns exactly the fields the client lists; the UI API returns the whole screen for that user. One GraphQL request isn’t one API call.
Your own door has its own contract. A custom Apex REST service hides your data model behind light request and response classes, never sObjects. You write it, you version it, and you own its errors, answered the web’s way.
A webhook needs a place to land. Salesforce has no built-in receiver; the integration layer usually is one. Every receiver checks the signature, the time and duplicates, then answers fast.
Separate users, one allowance. Every call runs as a user, and every caller draws from one daily allowance for the whole org. Long calls have a limit of their own.

The path through this chapter

Seven modules, each standing on its own.

All the Locked Doors. How many doors; the doors a browser uses; the doors a client uses; asking the org which doors it has; who’s still using an old one.
REST First. Pin the version; query, describe, one record; create, update and upsert; your automations still run; what changed since.
Many in One Call. sObject Collections, sObject Tree, Composite and Composite graph, and which one to use.
GraphQL and the UI API. The client decides; what GraphQL doesn’t change; give me the screen.
Your Own Door: Custom Apex REST. The standard door or your own; building it one step at a time; the contract is its own classes; answering errors the web’s way.
When Someone Calls You Back. Three ways to take a webhook in, and four things every receiver checks.
Who’s at the Door. The integration user, one allowance for the whole org, the long-call limit, watching the meter, and your lab bench.

Chapter 9 turns the arrows around: Salesforce as the client, calling out. Chapter 10 takes the bulk door, and chapter 11 the event doors.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

The door for every arrow coming in, from the shape of the work: REST, composite, GraphQL, the UI API, bulk, events, or your own.
The version every caller is on, pinned and written down, and how you’ll find the callers you didn’t write down.
The key every caller uses, so a resend updates instead of duplicating.
Where the all-or-nothing line is for records that belong together.
Standard door or your own, by whether the other team should know your inner workings, and with your own: its contract classes, its version and its error answers.
Where webhooks land, and who checks the signature, the time and duplicates.
One integration user per caller, and the allowance budgeted, with somebody watching the meter.

Beyond the exam: Salesforce says every major capability is now available as an API, an MCP tool or a CLI command, for an app, a person or an AI agent. An agent is one more caller at the door, with its own user, drawing on the same allowance. Chapter 22 is about those callers.

Explore

Salesforce Developers, API Library (opens in a new tab): the front door to Salesforce’s APIs.
Salesforce Developers, REST API Developer Guide (opens in a new tab): the standard door, in Salesforce’s own reference.
The API Guide: our own list of the documented doors, each with a link to Salesforce’s guide.

Next: Salesforce as an API Consumer