Skip to main content

Using HTTP Actions in Workflows

Once you’ve created an HTTP Action, you can use it in any workflow through the workflow builder’s library mode. This page covers adding actions to workflows, mapping inputs, and accessing outputs.

Adding an HTTP Action Step

1

Add an HTTP Request step

In the workflow builder, add an HTTP Request action step to your workflow.
2

Select Library Mode

At the top of the HTTP Request configuration panel, you’ll see two mode buttons:
  • HTTP Action (globe icon) — Library mode
  • Custom (send icon) — Custom mode
Select HTTP Action to use library mode.
3

Select an action

Choose an HTTP Action from the dropdown. The dropdown lists all actions in your project. Click the refresh button to reload the list if you recently created a new action.
4

Review action details

After selecting an action, the panel shows:
  • Method — Color-coded HTTP method badge
  • URL — The configured endpoint
  • Auth type — Authentication method badge
5

Map inputs

Map workflow variables to the action’s input variables (see Input Mappings below).
6

Save

Save the workflow. The step is now configured to use the selected HTTP Action.

Input Mappings

When an HTTP Action has input variables, you need to map them to values available in the workflow — event data, previous step outputs, or static values. The input mappings section shows each input variable from the HTTP Action with a value field. Use the variable picker to map workflow variables to each input.

Example

An HTTP Action “Create Stripe Customer” has input variables email and name. In the workflow:
Input VariableMapped Value
email{{trigger.email}}
name{{trigger.firstName}} {{trigger.lastName}}
Use the variable picker (type {{ in the input field) to browse available workflow variables — event trigger data and outputs from previous steps.

Output Variables

HTTP Action output mappings become workflow variables that downstream steps can reference.

Accessing Outputs

Output variables from an HTTP Action step follow the pattern:
outputs.http.<outputName>
For example, if the HTTP Action has output mappings for customerId and subscriptionId, downstream steps can use:
  • outputs.http.customerId
  • outputs.http.subscriptionId

Output Variables Section

The configuration panel shows a read-only list of output variables defined by the selected HTTP Action. These are set in the HTTP Action’s output mappings — to modify them, edit the HTTP Action directly.

Library Mode vs Custom Mode

The HTTP Request step supports two modes:

Library Mode (HTTP Action)

  • Select a pre-configured HTTP Action from your library
  • Map workflow variables to the action’s input variables
  • Outputs are defined by the action’s output mappings
  • Changes to the action apply to all workflows using it

Custom Mode

  • Configure method, URL, headers, and body inline
  • Full control over the request in this specific step
  • Output mappings configured per-step
  • Independent of other workflows
You can switch between modes at any time. Switching modes does not delete the other mode’s configuration — it’s preserved if you switch back.

Example: User Enrichment Workflow

Here’s a workflow that uses an HTTP Action to enrich user data on signup:
1. Event Trigger: user.signup
   └─ Receives: { userId, email }

2. HTTP Action: "Get User Profile from CRM"
   └─ Input Mappings:
      - email → {{trigger.email}}
   └─ Output Mappings:
      - companyName → body.data.company
      - role → body.data.role

3. HTTP Action: "Create Onboarding Task"
   └─ Input Mappings:
      - userId → {{trigger.userId}}
      - company → {{outputs.http.companyName}}
      - role → {{outputs.http.role}}

4. Send Email: Welcome email
   └─ To: {{trigger.email}}
   └─ Body includes: {{outputs.http.companyName}}
This workflow:
  1. Triggers on user.signup
  2. Fetches the user’s company info from a CRM using an HTTP Action
  3. Creates an onboarding task using another HTTP Action, passing along the CRM data
  4. Sends a personalized welcome email

Best Practices

If you call the same API in multiple workflows, create an HTTP Action. This centralizes the configuration and makes updates easier.
Avoid hardcoding values in your HTTP Actions. Use input variables for anything that changes between workflow executions — user IDs, emails, amounts, etc.
Always test your HTTP Action with realistic sample values in the test panel before adding it to a workflow. Verify that output mappings extract the expected values.
Choose clear output names like customerId or orderTotal rather than generic names like value1. These names appear in the variable picker throughout your workflows.
Not every HTTP request needs to be an HTTP Action. For unique, single-use API calls, custom mode keeps things simple.

What’s Next?