HTTP Callouts in Salesforce Flow: A Declarative Alternative to Apex-Based Integrations
Introduction
Integrations in Salesforce are traditionally implemented through Apex. A Flow collects data, calls an Apex method, Apex builds an HTTP request, sends it to an external system, parses the response, and returns the result back to Flow.
The problem is that many Apex integration classes contain little or no business logic. Their main responsibility is request construction, response parsing, and data translation between Flow and an external API.
Salesforce HTTP Callouts in Flow introduce a different model.
A Flow can define and invoke an external REST call directly, without using a custom Apex controller. The Flow describes the endpoint, request fields, and response fields declaratively.
This article looks at how HTTP Callouts in Flow work and how they compare to the classic Apex-based approach.
Why HTTP Callouts in Flow?
In the classic Salesforce architecture, external calls are implemented through Apex. From the perspective of a Flow, this usually looks simple: call an Apex action and receive a response. All integration details are hidden behind that method.
Under the hood, Apex is responsible for the following actions:
- Receiving parameters from Flow
- Constructing an HTTP request
- Setting headers and authentication context
- Sending the callout
- Parsing the response
- Returning a structured result
It means that every integration, even a very simple one, requires custom Apex.The Flow itself remains unaware of which fields are sent, which fields are returned, and how the endpoint is structured. A Flow cannot fully describe its own behavior. Part of the process exists visually in Flow Builder, and another part exists implicitly in Apex code.
HTTP Callouts in Flow allow it to:
- Define which endpoint is called
- Specify the HTTP method
- Describe request fields
- Describe response fields
This is especially valuable in scenarios where the integration is simple request/response and no complex transformations are required.
Setup Overview
Using HTTP Callouts in Flow requires three core elements:
- A credential configuration that defines how Salesforce authenticates to the external system.
- A named endpoint that represents the target system.
- An HTTP Callout Action created inside Flow Builder.
These elements are platform infrastructure. They are created once and reused across Flows.
So the workflow looks like this:
Create or select a Named Credential that points to the external system.
Illustration. Named Credential example
- In Flow Builder, add an Action and choose “Create HTTP Callout”.
Define HTTP method and relative path.
Illustration. Create new HTTP callout example
Define request and response fields.
Illustration. Request Body assignment example
No Apex class is created in this process. The result is a reusable Flow action that encapsulates the external call.
Conclusion
HTTP Callouts in Flow provide a practical alternative to Apex-based integrations in scenarios where the main requirement is a simple request/response interaction with an external REST API.
Traditionally, even basic integrations required a custom Apex layer responsible for constructing HTTP requests, sending them, parsing responses, and exposing results to Flow. In many cases, this Apex code contained little business logic and existed primarily as a transport layer.
With HTTP Callouts in Flow, this layer becomes optional. A Flow can define the endpoint, request structure, and response structure declaratively, and invoke the external system directly. This makes the integration contract explicit and visible inside the automation itself, reducing the amount of custom infrastructure code that needs to be written and maintained.
