Your Comprehensive Guide to HTTP Callouts in Salesforce Flow

Learn how Flow’s HTTP Callouts let declarative builders communicate with external systems — no Apex required. This guide covers setup, an example using the Chuck Norris API, response handling, and practical use-cases.

What are HTTP Callouts in Flow?

HTTP Callouts allow a Flow to send requests to and receive responses from external services. Instead of writing Apex, admins and declarative builders can configure an HTTP Callout action in Flow Builder; Salesforce creates the required backend artifacts (External Service, invocable actions, and Apex classes) for you.

Quick history

HTTP Callouts started in Spring ’23 (beta) with GET operations and expanded over subsequent releases to include POST, PUT, PATCH, and DELETE. Today they enable bi-directional communication between Salesforce Flows and third-party APIs.

Step-by-step: Build a simple Chuck Norris Joke Search Flow

This example demonstrates a GET callout that searches the Chuck Norris Jokes API and displays results in a data table.

1. Create a Named Credential

In Setup, go to Named Credentials and select New Legacy to avoid requiring an External Credential. For this example use:

  • Label / Name: ChuckNorrisSearch
  • URL: https://api.chucknorris.io/jokes/search

2. Build a Screen Flow

Create a Screen Flow with a Text screen component (e.g., “Give me a Chuck Norris joke about:”) and save the Flow.

3. Add the HTTP Callout Action

Add an Action > Create External Service in the wizard and select your Named Credential. Configure the callout:

  • Label: Get Chuck Norris Joke from Search
  • Method: GET
  • URL Path: leave blank (base URL is in the Named Credential)
  • Add URL parameter: key = query, Data Type = String, Require = TRUE

Use Connect for Schema to validate the response and test a sample value (e.g., beach).

4. Review and parse the response

The API returns JSON with a total field and a result array. Each item contains a value (the joke). Example snippet:

{
  "total": 14,
  "result": [
    {
      "id": "oJFv_vZ5SZ2JBbY-1u6ZgA",
      "value": "When Chuck Norris goes to the beach, he doesn't need sunblock, the sun needs Chuckblock."
    },
    {
      "id": "bYp7PdO5QLS7LbB_wZRYLg",
      "value": "Chuck Norris shot an Eagle on the 14th hole at Pebble Beach..."
    }
  ]
}

5. Display results in a Screen

  • Add a Screen with a Data Table component.
  • Source Collection: {!Get_Chuck_Norris_Jokes.2XX.result}
  • Unique Identifier: id
  • Column Source Field: value (label it “Chuck Norris Joke”)

6. Test the Flow

Use the Flow Debugger to provide search terms and confirm the data table shows jokes. Test edge cases: zero results, one result, many results.

Practical use-cases

  • Validate customer data against an external system before save
  • Retrieve shipping updates from carriers via tracking codes
  • Check stock availability for products
  • Trigger third-party eSignature or SMS providers
  • Call pricing engines for complex quotes

Best practices

  • Develop and test in a Sandbox or Developer Org — avoid early production testing.
  • Use Named Credentials for secure, centralized endpoint configuration.
  • Handle collections and null/empty responses in your Flow design.
  • Respect API limits and consider retry patterns or queueing for high-volume usage.
  • Log or monitor callouts (platform events or custom logging) for observability.

Conclusion — why this matters

HTTP Callouts in Flow dramatically expand what admins and declarative builders can achieve without code. They shorten delivery time, reduce developer dependency for integration tasks, and let teams build richer user experiences that connect Salesforce to the wider ecosystem. For admins and developers, knowing when to use a Flow callout vs a programmatic integration is a valuable skill that improves agility and governance.

Author: Tim Combridge — Technical Content Writer