External Services From an OpenAPI Spec

Module 2 of 6 in the chapter The Admin’s Integration Toolkit, chapter 4 of the Integration Architect course. Each module stands on its own. Previous: Named and External Credentials · Next: Flow HTTP Callouts

The question this module answers: How does an admin call another system’s API from a flow, with no code?

Back to the line this chapter started with:

Endpoint and authentication live in the named credential. Protocol lives inside the OpenAPI spec.

The last module was the first half. This one is the second: the protocol, from the contract. Put the two together, and Salesforce can call the other system from a flow.

External Services came first, as the way to make callouts from inside Salesforce without Apex code. In Salesforce’s words, it connects “your Salesforce org to an external API by using zero lines of code” (External Services (opens in a new tab), Salesforce Help, checked 2026-11-01).

The Secret Is the Spec

What External Services needs is the API’s specification, the OpenAPI file from The Contract. It says what the addresses are going in, what the return values are coming out, and what errors you could get. Everything Salesforce needs to know about the protocol is in that file.

So the secret of External Services is having that file. Typically, the company that runs the API provides it: you download it from their documentation, or point to where they host it.

And when they don’t? You used to build one by hand, and it took hours to get it nailed down. Now it’s a matter of a moment: give an AI tool a sample response and the provider’s documentation, ask it to merge them into an OpenAPI 3.0 file, and then check it, the way AI in the Work showed. Check especially for what External Services can’t take: it reads OpenAPI 2.0 and 3.0, not the newer versions, and not placeholders in the server address (OpenAPI 2.0 and 3.0 Support (opens in a new tab), checked 2026-11-01).

Register the Spec

Registering takes a few steps, and no code. Say Steve Trucking wants its flows to call Redrock’s shipment API:

1. Identify the API, and get its OpenAPI file.
2. Create the named credential, with its external credential, as in module 1: Redrock’s address, and how to sign in to Redrock.
3. Register the external service: add it from the API spec, by uploading the file or pointing to where it’s hosted, and choose the named credential.
4. Choose the operations you want. Salesforce shows each one from the file: the method, the input parameters, and the responses: a 200 for success, a 400, a 404.
5. Use it in a flow.

That’s the three things from chapter 2 again: where, how to get in, and what to say. The named credential brings the first two; the spec brings the third.

Click to enlarge

From the contract to an action.

Use the Actions

Think of an external service as a clean wrapper around the other system. It takes what that system can do, as the spec describes it, and wraps each operation as an action with named inputs and outputs. The admin doesn’t see the address, the headers, the JSON or the sign-in. They see an action, something like Get Shipment Status, and it plugs into a flow like any other action. That’s the point: the other system’s capabilities, ready for admins to use.

Two things keep that picture accurate. The wrapper holds only what the spec describes, and only the operations you chose. If Redrock’s API can do something the spec doesn’t say, the wrapper can’t do it either. And the wrapper adds no logic of its own. It calls the API, and what the API returns is what the flow gets.

Once it’s registered, every operation in the spec becomes an action. In a flow, you add it like any other action, map your fields to its inputs, and read its outputs: the shapes from the spec’s schemas, ready to use.

And it’s not only Flow. Salesforce makes the same operations available “in Apex, or as External Services action types within point-and-click automation tools such as Flow Builder, Orchestrator, Einstein bots, or OmniStudio Assets,” and as custom agent actions for Agentforce (External Services (opens in a new tab)). In Apex, the operations arrive as types that match the spec, so the compiler checks your code against the contract.

That last one matters more every year. Register Redrock’s contract once, and an agent can call it as an action, through the same named credential, the same gate. Chapter 21 comes back to agents and their tools.

When the Spec Changes

There are two ways to bring the spec in, and the difference shows up later. If the other company hosts it, you can come back and bring in the new version when it changes. If you uploaded your own copy, nobody tells you when theirs changes. What if it changes? That’s the downside.

Either way, the external service is in use. Flows, Apex and agents depend on its actions. So Salesforce lets you register an updated schema, but only with changes it can support (Schema Update Support (opens in a new tab), Salesforce Help, checked 2026-11-01):

• Adding is safe: new operations, objects, fields and parameters. So is changing a description or an example.
• Some removals are allowed, but can break things. Deleting an optional parameter or field “can lead to errors in flows, Apex, Agentforce agents, or other components that reference them.” Check them after.
• Some removals aren’t allowed while they’re in use: an operation in use, a required parameter or field, an object an operation needs. And watch for renames: “A name change is considered deleting the element with that name and adding the element with the new name.”

Click to enlarge

When the spec changes: adding is safe, removing breaks.

That’s a version is a promise, from the other side. When Redrock changes its contract, Steve Trucking’s flows feel it. So agree with the other side how they’ll tell you, and keep a list of which flows, Apex and agents use each external service.

When There’s No Spec

External Services is best when the other system is a REST service with an OpenAPI file. But typically, you don’t get API specs. You get documentation, and a tool like Postman, and you figure it out. For that, there’s a newer way: the Flow HTTP callout, which builds the shape from a sample instead of a spec. It even registers an external service for you behind the scenes. That’s the next module.

What an Architect Decides Here

• For every API Salesforce calls from Flow, whether there’s an OpenAPI file, and who provides it.
• If AI drafted the file, who checked it, and that it’s OpenAPI 3.0 or 2.0 with a plain server address.
• Hosted or uploaded, and how you’ll hear when the other side’s contract changes.
• Which flows, Apex classes and agents use each external service, so you know what a change touches.
• Which operations to register: only the ones you need.

Beyond the exam: what AI changes. Two things. AI drafts the spec when the provider doesn’t publish one, so External Services is open to many more APIs than it used to be. And a registered external service is an action an agent can use. That’s powerful, and it means the contract, the named credential and the permission set now decide what an agent can do in another system, not just what a flow can. Chapter 21.

Explore

• Salesforce Help, External Services (opens in a new tab) and Schema Update Support (opens in a new tab), checked 2026-11-01.
• Salesforce Help, OpenAPI 2.0 and 3.0 Support (opens in a new tab), checked 2026-11-01.
• The next module, Flow HTTP Callouts: when there’s no spec.