Flow HTTP Callouts

Module 3 of 6 in the chapter The Admin’s Integration Toolkit, chapter 4 of the Integration Architect course. Each module stands on its own. Previous: External Services From an OpenAPI Spec · Next: Who’s Calling In

The question this module answers: How does an admin call another system’s API from a flow when there’s no OpenAPI spec?

The whole problem with External Services is the spec you have to get. And typically, you don’t get API specs. You get documentation. You sit there with a tool like Postman and figure the API out, call by call. Building the spec from that was the hard part.

So Salesforce made a way that doesn’t need one: the HTTP callout, right inside Flow. In Salesforce’s words, it connects “flows to external APIs without coding” (Connecting to an API Without a Connector Using HTTP Callout (opens in a new tab), Salesforce Help, checked 2026-11-01). It’s visual coding: coding without writing lines of code.

But everything from the last three chapters still applies. The get, the post, the put, the patch, the delete. The status codes. The named credential. You still need to know it all. The HTTP callout doesn’t hide the call. It just builds it for you.

What You Still Need

Two things, before you start.

A named credential. The same gate from module 1: the address, who’s allowed, and how to sign in. The HTTP callout uses it for every call. No address and no secret goes in the flow.

A sample. One real example of what the API sends back, in JSON. Salesforce suggests taking it from the API’s documentation, or calling the API yourself with “a third-party API platform” to get one. And its advice is worth repeating: “Start with an API that’s well documented” (Configure an HTTP Callout Action (opens in a new tab), checked 2026-11-01). If the documentation is wrong, you’ll find out the slow way.

Build One

Say Steve Trucking wants a flow to ask Redrock for a shipment’s status. In Flow Builder, you add an Action element and choose Create HTTP Callout. Then:

1. Name the external service, and choose the named credential. Salesforce fills in the address from it.
2. Describe the call. Give it a label, like Get Shipment Status. Choose the method. Generally, a GET brings data in, and the others change data in the other system. Add the path, /v1/shipments/{shipmentId}/status, with the part that changes in curly brackets, and any query parameters.
3. For a POST, PUT, PATCH or DELETE, paste a sample of the request body.
4. Paste a sample of the response. This is the superpower. Paste in some sample JSON, and Flow figures out the shape for you: the fields, their types, the lists inside. Check what it found, and fix any type it got wrong.
5. Save. Flow Builder creates the action, and an external service behind it.

Here’s the sample for Redrock’s status call:

{
  "shipmentId": "D-1042",
  "state": "IN_TRANSIT",
  "eta": "2026-11-03T16:00:00Z",
  "stopsLeft": 2
}

From that, Flow knows there’s a shipment ID, a state, a time and a number. In the flow, the action takes a shipment ID and gives back those four fields, ready to use in a decision or an update.

Click to enlarge

From a sample to an action.

That last step matters. Every HTTP callout action creates an external service registration (HTTP Callout Considerations and Limits (opens in a new tab), checked 2026-11-01). Take away the spec, and what’s left is External Services: the same wrapper, built from a sample instead of a contract. So the action is reusable, by other flows, across the org.

What One Sample Can’t Tell You

You’ve seen this before. In AI in the Work, AI drafted a contract from one sample, and got the shape right. What it couldn’t know was everything the sample didn’t show. Flow has the same problem, for the same reason. One sample shows what’s there. It can’t show the rules.

Salesforce lists the gaps (HTTP Callout Considerations and Limits (opens in a new tab)):

• No list of allowed values. Redrock’s state can only be a few things: booked, in transit, delivered. The sample shows one. Flow sees a plain text field, because enums aren’t supported.
• Some number types. Float and long aren’t supported. Set them to integer or double.
• Lists of mixed types. A list must hold one type: [1, 2, 3] works; ["one", 2] doesn’t.
• An empty answer. It should be {} or [], not an empty string.
• Request headers. You can’t set them on the action. Put them in the named credential, or edit the spec, which turns the HTTP callout into a standard external service.
• Depth. Up to 15 levels of nested fields and objects.

Click to enlarge

What one sample can’t tell you.

So read the documentation beside the sample. And for anything advanced, complicated schemas and the intricacies they bring, you’ll still need Apex. That’s chapter 9.

Plan for the Answer

Not every answer is a 200. You know the codes from chapter 3: the 200s are success, the 400s are the client’s to fix, the 500s are the server’s. For an HTTP callout, Salesforce treats “a response status code of 300 or greater” as an error, and says to handle it “by using a fault path” (HTTP Callout Considerations and Limits (opens in a new tab)).

So you need to be able to handle these errors in your flows, with branching. Every callout action gets a fault path. What does the flow do with a bad request? With a shipment Redrock has never heard of? With Redrock down for the night? Decide, before it happens. Module 6 goes deeper: what you’ll see, and where to look first.

One more rule. A record-triggered flow can’t make a callout while the record is still being saved. Put the callout on an asynchronous path, which runs “after the original transaction for the triggering record is successfully committed” (Connect a Record-Triggered Flow to an External System Using an Asynchronous Path (opens in a new tab), Salesforce release notes, checked 2026-11-01). Module 6 shows the error you’ll see when you forget.

Spec or Sample?

Both ways end in the same place: an external service, an action in the flow, and the named credential at the gate. The difference is where the shape comes from.

Click to enlarge

Spec or sample: two ways to the same action.

If there’s a spec, use External Services: the contract brings the rules with it. If there’s no spec and you need a quick, straightforward call, the HTTP callout is the right tool. And if the call is complicated, with deep schemas, headers that change per call, or logic around the response, that’s Apex.

What an Architect Decides Here

• For each call from a flow, spec or sample, and who checked the shape Flow built.
• Which named credential each callout uses, and who’s allowed through it.
• What every callout’s fault path does, for a 400, a 404 and a 500.
• That callouts in record-triggered flows run on an asynchronous path.
• When a call has outgrown Flow, and moves to Apex.
• Where the samples come from: the documentation, or a test system. Never real customer data.

Beyond the exam: what AI changes. AI can write the sample for you from the API’s documentation, and help you read what Flow inferred from it. Check it against the documentation, the way chapter 3 checked the contract: AI can’t know what the documentation doesn’t say. And give it made-up data only. A sample copied from production is real customer data, pasted into an AI tool.

Explore

• Salesforce Help, Connecting to an API Without a Connector Using HTTP Callout (opens in a new tab), Configure an HTTP Callout Action (opens in a new tab) and HTTP Callout Considerations and Limits (opens in a new tab), checked 2026-11-01.
• Salesforce Help, How Flows Run in Transactions (opens in a new tab), checked 2026-11-01.
• Salesforce release notes, Connect a Record-Triggered Flow to an External System Using an Asynchronous Path (opens in a new tab), checked 2026-11-01.
• The next module, Who’s Calling In: the other direction, another system calling into Salesforce.