Intermediate10 min

Webhooks and Calling APIs

When no ready-made integration exists, two tools cover almost everything: webhooks let other systems trigger your flow, and a generic HTTP request step lets your flow talk to any API. Together they remove the ceiling on what you can connect.

Webhook as a trigger

Add a Webhook trigger and the tool gives you a unique URL. Any service that can send an HTTP POST to that URL will start your flow and hand it the payload. This is how you connect things that have no native integration.

zsh - test a webhook
# fire a test payload at your n8n webhook
$curl -X POST https://your-n8n.app/webhook/lead \
$ -H 'Content-Type: application/json' \
$ -d '{"name":"Ada","plan":"pro"}'
{ "received": true, "workflow": "started" }
$

Calling an API with HTTP Request

The HTTP Request node sends a request to any endpoint. You set the method, URL, headers (including auth), and body. The response comes back as data you can use in later steps, just like any other node.

HTTP Request node config
{
  "method": "POST",
  "url": "https://api.example.com/v1/contacts",
  "headers": {
    "Authorization": "Bearer {{ $env.API_KEY }}",
    "Content-Type": "application/json"
  },
  "body": {
    "name": "{{ $json.name }}",
    "plan": "{{ $json.plan }}"
  }
}
Never paste keys into the flow
Store API keys and tokens in your tool's credentials manager or environment variables, not inline in a node. Inline secrets leak through exports, screenshots, and shared workflows.
Read the response status
Always branch on the HTTP status. A 200 means success; a 429 means slow down; a 500 means retry later. Treating every response as success is the most common reason flows silently lose data.

Hands-on tasks