[ blog · tutorial ]8 min read

Add Real-Time Web Search to an n8n AI Agent

Sarah Choy·Published September 23, 2026·8 min read

n8n has no built-in web search node, and the two workarounds people reach for behave very differently once an AI Agent is driving them. Here is the HTTP Request Tool route, the sub-workflow route, and the failure mode that sends most people back to the forum.

TL;DR

• •n8n ships no native web search node — you wire one yourself with the HTTP Request Tool or a sub-workflow tool.
• •The HTTP Request Tool uses its own placeholder mechanism; $fromAI() is the newer expression and is not reliable inside that node yet.
• •The sub-workflow route (Call n8n Workflow Tool) is slower to set up but gives you $fromAI(), retries, and a normal HTTP Request node inside.
• •Point either one at POST https://www.apipick.com/api/search/web with an x-api-key header — 15 credits per call, charged only on HTTP 200.
• •Failed calls cost nothing, which matters in n8n because an agent loop that misfires will retry several times before it gives up.

Why does n8n have no web search node?

Because search is a vendor decision, not a platform primitive. n8n gives you an AI Agent node, a set of tool sub-nodes, and an HTTP escape hatch — and leaves the choice of search provider to you. That is the right call architecturally, and it is also why every "n8n web search" thread ends with someone pasting an HTTP Request node screenshot.

There are exactly two mechanisms that let an agent decide what to search for, rather than you hard-coding the query. This post covers both, and the difference matters more than the docs suggest.

Which two routes can an agent actually use?

How do you wire the HTTP Request Tool?

Add an AI Agent node, then attach an HTTP Request Tool to its Tool connector. Configure it like this:

Method:        POST
URL:           https://www.apipick.com/api/search/web
Authentication: Generic Credential Type → Header Auth
  Name:        x-api-key
  Value:       pk_yourkey

Send Body:     on
Body Content Type: JSON
Specify Body:  Using JSON
JSON:
{
  "query": "{searchQuery}",
  "max_num_results": 5
}

Then scroll to Placeholder Definitions and add one row:

Name:        searchQuery
Description: The search query to run on the live web. Write it the way a
             person would type it into a search box — no operators, no
             quotes, no site: filters.

That description is the whole prompt the model sees for this parameter. Vague descriptions here are the number one cause of an agent that searches for the user's question literally.

Finally, tell the agent when to reach for it. In the AI Agent node's system message:

You have a web_search tool. Use it whenever the answer depends on
information after your training cutoff, on prices, on news, or on
anything a person would check by opening a browser. Cite the URLs
you used. If the search returns nothing useful, say so — do not guess.

What is the $fromAI trap?

Everywhere else in n8n's AI tooling you fill dynamic values with {{ $fromAI('query', 'the search query', 'string') }}. It is expressive, self-documenting, and typed. It is also not the mechanism the HTTP Request Tool uses, and dropping it into that node has been a recurring source of executions that fail the moment the agent calls the tool.

How do you build the sub-workflow route?

1. Create a new workflow. First node: When Executed by Another Workflow. Define one input field, query (string).
2. Second node: an ordinary HTTP Request node — POST to https://www.apipick.com/api/search/web, header auth x-api-key, JSON body { "query": "{{ $json.query }}", "max_num_results": 5 }.
3. Third node: a Code or Set node that flattens the response to just what the model needs — title, url, snippet. This is the step the HTTP Request Tool cannot give you.
4. Save it. Back in the agent workflow, attach a Call n8n Workflow Tool node, point it at this workflow, and fill the query field with {{ $fromAI('query', 'The search query to run on the live web', 'string') }}.

The flattening step in point 3 is worth the extra five minutes on its own. A raw search payload carries fields the model will happily spend tokens reading and never use.

// Code node — keep three fields, drop the rest
return $input.all().flatMap(item =>
  (item.json.results ?? []).map(r => ({
    json: { title: r.title, url: r.url, snippet: r.snippet }
  }))
);

How do you handle failures and cost?

An n8n agent that has a misconfigured tool does not fail once — it fails, reconsiders, and calls again, often three or four times inside a single execution. With a per-call subscription meter that is a line item. With only-on-success billing it is free: credits are deducted on HTTP 200 and nothing else, so a 401 from a wrong header or a 400 from a malformed body costs zero.

Two things worth setting anyway:

• Timeout. Set the HTTP node's timeout to something the agent loop can survive — 20 seconds is generous for a search call and still leaves room for the model to recover.
• Result cap at the source. max_num_results accepts 1–5 and defaults to 5. Asking for more results is rarely what makes an answer better; following up with Extract on the best two URLs usually is.

What else can you hang off the same key?

The same header and the same billing model cover the rest of the catalogue, so a second tool is a copy of the first with a different path. The three that come up most in n8n workflows:

• News Search — POST /api/search/news, for briefing and monitoring workflows. See the morning briefing build for a full example.
• URL Extract — POST /api/extract, 2 credits per URL, for the read-after-search step.
• Academic Search — POST /api/search/academic, 5 credits, when the workflow is research rather than news.

If you are choosing a provider rather than wiring one you have already picked, the 2026 web search API comparison covers the tradeoffs. Start with a free key — 100 credits, no card.

Written by

Sarah Choy

CEO, API Pick

Sarah Choy is the CEO of API Pick. She writes about building production-ready APIs for AI agents and LLM workflows.