Skip to content
SteveTechArcSteveTechArc Courses

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

Section titled “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

Section titled “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.

From a sample to an action On the left, what you bring: the named credential, with the address and the sign-in; and one sample of the response, pasted in. Both point into the HTTP callout in Flow Builder, in navy, where you choose the method and the path. Flow infers the shape from the sample. It creates two things: an external service, made behind the scenes, and a flow action, Get Shipment Status, ready to use. Underneath: no spec, just a sample; Flow builds the shape, and an external service behind it. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-INT-AT-07", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} WHAT YOU BRING IN FLOW BUILDER The named credential the address and the sign-in One sample response JSON, pasted in The HTTP callout the method and the path An external service made behind the scenes A flow action Get Shipment Status, ready to use where, who and how the shape, inferred creates creates No spec, just a sample. Flow builds the shape, and an external service behind it. © 2026 Twinshark LLC · stevetecharc.com
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

Section titled “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.
What one sample can't tell you Two panels. What the sample shows, in green: the field names; the types it can see, text, number, true or false; the lists, and what's in them; how the fields nest. What it can't show, in amber: which fields are required; the allowed values, so state becomes plain text; the other answers, a 404 or a 500; float and long numbers, and request headers. Underneath: one sample shows what's there; the rules come from the documentation, and from you. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-INT-AT-08", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} What the sample shows Flow infers it The field names The types it can see: text, number, true or false The lists, and what's in them How the fields nest What it can't show yours to know Which fields are required The allowed values: state becomes plain text The other answers: a 404, a 500 Float and long numbers, request headers One sample shows what's there. The rules come from the documentation, and from you. © 2026 Twinshark LLC · stevetecharc.com
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

Section titled “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?

Section titled “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.

Spec or sample Two panels side by side. External Services, from a spec: the shape comes from the contract; all the operations at once; the rules come with it, what's required and the allowed values; when the spec changes, register the new version. HTTP callout, from a sample: the shape comes from one example; one action at a time, built inside the flow; the rules are yours to know; when the API changes, edit the action. Underneath: both use the named credential, and both end as an external service and an action. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-INT-AT-09", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} External Services from a spec The shape comes from the contract All the operations at once The rules come with it: required, allowed values When it changes: register the new version HTTP callout from a sample The shape comes from one example One action at a time, inside the flow The rules are yours to know When it changes: edit the action Both use the named credential. Both end as an external service and an action. © 2026 Twinshark LLC · stevetecharc.com
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

Section titled “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

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.