Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The quick version: the HTTP Callout action lets you define a REST call in Flow Builder by pasting a sample response, which Salesforce turns into a typed data structure you can reference like any other flow resource. Authentication comes from a named credential, so no keys live in the flow. It is genuinely good for straightforward JSON APIs and genuinely poor for anything with awkward authentication, paging, or a response shape that varies by request.

Setting one up

From the New Action panel in Flow Builder you create an HTTP Callout. The wizard asks for a service label, a named credential, and then the call itself: method, relative path, query parameters, and any headers.

The interesting step is the response. You paste a real sample body from the API and Salesforce derives a schema from it, producing an output structure with named, typed fields. After that the response is addressable the way a record variable is, with autocomplete, rather than as a blob of text you have to parse.

What gets created behind the scenes is an External Service registration and a matching action. It is metadata, it lives in source control, and it deploys between orgs.

The sample response is the contract

This is the part that bites people. The schema is derived from the sample and nothing else.

  • A field absent from your sample does not exist for the flow, even if the API returns it every time. Paste a complete example, not a trimmed one.
  • A field whose sample value is null gives the generator nothing to infer a type from. Supply a sample where every field has a representative value.
  • An array needs at least one element in the sample, and the generator types the whole array from that element.
  • Numbers that arrive as strings in the sample are typed as text, and you will be converting them in every formula afterwards.

Authentication

The callout uses a named credential, which means the endpoint host and the authentication live in Setup rather than in the flow. That is the right split. Use an external credential with the appropriate authentication protocol, grant the relevant permission set access to it, and the flow never sees a token.

Two things to check before you blame the flow:

  • The running user needs access to the external credential’s principal through a permission set. A flow running in system context still resolves the credential, but a user-context screen flow will fail for anyone who lacks it.
  • The named credential’s URL plus the path you configured must produce the exact endpoint. Doubled or missing slashes produce a 404 that looks like a flow problem.

Error handling

A non-2xx response makes the action fault, so draw a fault connector off it. The message is available as {!$Flow.FaultMessage}, and the action also exposes the HTTP status code, which is what you should branch on:

Decision on status code
  401 or 403  -> credential problem, log and alert an admin
  404         -> record does not exist remotely, treat as a normal outcome
  429 or 5xx  -> transient, stamp the record for a retry job
  otherwise   -> log and stop

An API that returns HTTP 200 with an error payload in the body will not fault at all. Read the body and decide for yourself. This is common enough that it is worth checking the API’s behaviour before you build the happy path.

Where it has to run

You cannot make a callout after DML in the same transaction. In a record-triggered flow that means the callout belongs on the asynchronous path, always. A screen flow is fine because the callout happens before the user saves anything, and a scheduled flow is fine as long as the callout comes before any record updates in the same interview.

When to use Apex instead

The HTTP Callout action is a good fit for a single request with a predictable JSON response. Write an invocable Apex class when you need OAuth token exchange the platform does not handle, pagination across multiple requests, retry with backoff, a response shape that changes depending on input, XML, or multipart uploads. Wrapping that in an invocable action still lets the flow own the process while Apex owns the protocol.

Frequently asked

Can I change the schema after creating the action? You edit the action and supply a new sample response. References in flows to fields that disappear will break, so check before saving.

Does it work in a before-save flow? No. Before-save flows do not allow actions at all.

Is the request logged anywhere? Not by default. Turn on debug logs with the callouts category for troubleshooting, and write your own log record from the flow for anything you need to keep.