Send an HTTP Request From an Automation

The Send an HTTP request action lets an automation reach out to another service. When the automation runs, Bluprint makes an HTTP call to a URL you choose — so you can trigger a deploy, post to a service that isn't a built-in integration, or notify your own backend.

It's the outbound counterpart to the Trigger Automations With an Incoming Webhook trigger. New to automations? Start with Automations Overview.

What You Can Configure

1. Add the action

   In the builder, click Add action and choose Send HTTP request.

2. Pick a method and URL

   Choose the HTTP method (GET, POST, PUT, PATCH, or DELETE) and enter the destination URL. The URL can include {{ row.* }} tokens, so you can send data from whatever triggered the automation.

3. Add headers (optional)

   Add any headers the receiving service needs — for example an Authorization header with an API key. Header values support tokens too.

4. Write the body (optional)

   For methods that send a body, add JSON or raw text. A JSON body is sent with Content-Type: application/json unless you set your own. Tokens work here as well.

Expand

Tokens Make It Dynamic

Every template field interpolates tokens from the run, so the request carries real data:

{
  "title": "{{ row.title }}",
  "status": "{{ row.status }}"
}

If an earlier step in the automation was a Generate with AI action, its output is available too as {{ ai.<name> }}. See Generate Text and Values With AI. Start typing {{ in any field to see the full list of available tokens.

Security Limits You Should Know

Because this action can call arbitrary URLs, Bluprint enforces a few guardrails automatically:

• Public hosts only. Requests to localhost, private IP ranges, and other internal addresses are blocked, and redirects onto them aren't followed. Only http and https URLs are allowed.
• A 10-second timeout. A request that hangs is cancelled so it can't stall the automation.
• A trimmed response. Bluprint stores the response status and a short snippet of the body in the logs, not the entire payload.

Reading the Result

Every run records what happened in Execution Logs. A successful call shows the HTTP status and a snippet of the response; a failure shows the status code or error, so you can tell a bad URL from an authentication problem at a glance.