How to Use Talordata SERP API in Dify Workflows

Dify is great when you want to build an AI app without turning every small idea into a backend project.

You can create a workflow, add an LLM node, connect tools, pass variables between nodes, and ship a usable assistant fairly quickly. But there is one problem that shows up in almost every real app:

The model does not know what happened after its training cutoff.

That is fine for stable knowledge. It is not fine for news, pricing, SEO rankings, competitor pages, product launches, policy updates, or market research. In those cases, the workflow needs a live data source.

That is where a SERP API fits.

With Talordata SERP API inside Dify, your workflow can search the web, receive structured search results, and pass fresh context into an LLM node. Talordata’s Dify page describes the integration as a way to bring real-time search information and multi-search-engine capabilities into Dify workflows and agents.

What we will build

A simple Dify workflow:

User question
→ Talordata SERP search tool
→ LLM node reads search results
→ Final answer with useful summary and source links

This is enough for many practical tools:

• real-time research assistant

• market trend monitor

• SEO content brief generator

• competitor tracking workflow

• news summary agent

• RAG workflow with live search context

• product or pricing research assistant

The point is not to make the workflow complicated. The point is to give it fresh search context when fresh context matters.

Why add SERP data to Dify?

A normal Dify app can reason over prompts, files, knowledge bases, and user input. But when the answer depends on current web information, the LLM alone is not enough.

For example:

What are the latest pricing pages for CRM tools?
Which pages rank for “best project management software” today?
What are recent news results about this company?
What questions appear around this product category?

For these questions, the workflow should search first.

Talordata’s Dify page explains the same problem from the workflow side: LLMs have knowledge cutoffs, crawlers require maintenance, and a SERP API can give agents real-time web results directly inside Dify workflows.

Step 1: Install the Talordata SERP plugin in Dify

Start inside Dify.

The Talordata Dify page says the plugin can be installed by downloading/importing from GitHub, then adding it into Dify. It also says that once the tool is selected, Dify will show fields such as query, device, location, gl, and hl in the parameter panel.

A practical installation flow looks like this:

Dify Plugin / Marketplace area
→ Install from GitHub or import plugin package
→ Add Talordata SERP plugin
→ Configure provider credentials
→ Use the search tool in a workflow or agent

The GitHub repository describes the plugin as exposing Talordata SERP API as Dify tools. It also says you should configure a Talordata SERP API key in the plugin provider settings.

Step 2: Configure your SERP API key

After installation, add your Talordata SERP API key in the plugin provider settings.

One detail matters here: use a SERP API key, not a dashboard login JWT token. The plugin README specifically notes that the API key should look like sk_xxxxxxxxx..., and that a Talordata login JWT is only for dashboard APIs such as quota, token management, statistics, and Playground schema.

So the credential setup should be:

Provider: Talordata SERP
Credential: SERP API key
Do not use: dashboard login JWT

This sounds small, but it saves a very boring afternoon of “why is my key not working?”

Step 3: Add a search tool to your Dify workflow

Once the plugin is ready, add one of the search actions into your workflow.

The plugin repository says it exposes one Dify action for each enabled SERP engine, plus a raw request action for advanced use. It lists Google actions such as google_search, google_image_search, google_news_search, google_shopping_search, google_maps_search, google_scholar_search, and google_trends_search; Bing actions such as bing_search, bing_image_search, bing_maps_search, bing_news_search, bing_shopping_search, and bing_videos_search; plus yandex_search and duckduckgo_search.

For a first workflow, use google_search.

A simple node chain:

Start node
→ Talordata google_search tool
→ LLM node
→ Answer node

The tool node handles the search. The LLM node turns the search results into something readable.

Step 4: Map user input to the search query

Most workflows should map the user’s input into the tool’s query field.

For example:

User input variable: {{query}}
Tool field: q

The plugin README gives a similar usage flow: install the plugin, configure provider credentials, add a search tool such as Bing Search or Google Search to a workflow or agent, map the user query to the tool’s query field such as q, run the workflow, and consume the returned structured JSON results.

A basic Google Search node might use:

{
  "q": "{{query}}",
  "gl": "us",
  "hl": "en",
  "num": 10
}

You can expose gl, hl, location, or device as workflow inputs later. For the first version, keep them fixed.

Step 5: Decide what the LLM should do with the SERP data

Search results are not the final answer.

They are raw ingredients.

Your LLM node should have a clear job. For example:

You are a research assistant.

Use the SERP results to answer the user’s question.
Focus on title, snippet, URL, source, and ranking position.
Do not invent facts that are not supported by the results.
Include source URLs when they help the user verify the answer.
Keep the answer concise.

For SEO content research, the prompt can be more specific:

Read the search results and identify:
1. Common search intent
2. Repeated content angles
3. Important competing pages
4. Questions users may ask
5. A suggested content outline

For market monitoring:

Read the search results and summarize:
1. Recent market signals
2. Competitors mentioned
3. Product or pricing changes
4. Newsworthy updates
5. URLs worth reviewing manually

The trick is to avoid asking the model to “analyze everything.” That usually produces fog. Give it a small job with a clean output shape.

Step 6: Use the right search parameters

A Dify workflow becomes much more useful when it searches with context.

Useful parameters include:

Talordata’s Dify page says the parameter panel can present fields such as query, device, location, gl, and hl; it also describes flexible search parameters including natural language query input, geo and language support, pagination, and search types such as web, news, video, and image. View the complete integration tutorial>>

For example, an SEO workflow may use:

{
  "q": "{{keyword}}",
  "gl": "us",
  "hl": "en",
  "location": "New York, United States",
  "device": "desktop",
  "num": 10
}

A news monitoring workflow may use a news search action instead of normal web search.

A product research workflow may use Shopping search.

Step 7: Use raw requests only when needed

The plugin also provides raw_serp_request for advanced cases.

The repository explains that generated actions fix their own engine parameter and expose common SERP parameters directly in the Dify node. It also says raw_serp_request can be used when you need to pass custom params_json overrides for advanced request parameters.

Example raw request shape:

{
  "engine": "google",
  "q": "coffee",
  "params_json": "{\"gl\":\"us\",\"hl\":\"en\",\"num\":10}"
}

For most workflows, start with the normal generated action.

Use raw requests only when the standard tool node does not expose the exact parameter you need.

Common workflow examples

Real-time research assistant

User asks a recent question
→ Search Google
→ Summarize top results
→ Return concise answer with source URLs

SEO content brief generator

User enters keyword
→ Search Google
→ Extract top pages, snippets, PAA-style questions if available
→ Generate search intent, outline, FAQ, and content angles

Market intelligence workflow

User enters brand or competitor name
→ Search web/news
→ Extract recent mentions
→ Summarize market signals
→ Output “watch list” URLs

RAG with live search

User asks question
→ Search web
→ Pass SERP snippets and URLs into LLM node
→ LLM combines live search context with internal knowledge base

Talordata’s Dify page lists similar use cases, including RAG real-time augmentation, AI agent web connectivity, market and trend intelligence, and SEO/content intelligence.

Best practices

Keep the first workflow boring. One search node, one LLM node, one answer node. Fancy workflows can come later.

Do not search for everything. Only search when the user asks about recent, source-dependent, location-dependent, or market-dependent information.

Store useful metadata when possible. Query, country, language, device, timestamp, and result URLs are important for debugging and historical comparison.

Ask the model to quote sources lightly. You do not need a citation after every sentence, but URLs should be visible when the answer depends on search results.

Avoid sensitive personal data in search queries. The plugin README also recommends avoiding unnecessary sensitive personal data in search queries.

Watch for quota and rate limits. The plugin README notes that availability, freshness, latency, quota, and rate limits depend on the Talordata SERP API and the user’s account plan.

Start your free trial of TalorData>>

FAQ

What is Talordata SERP API for Dify?

It is a Dify plugin integration that lets Dify workflows and agents access structured search engine results from Talordata SERP API. The search results can then be used by LLM nodes for answers, summaries, research, SEO workflows, or RAG context.

Do I need to write code to use it in Dify?

Not for the normal workflow. After installing the plugin and configuring the API key, you can add search tools as workflow or agent nodes and map fields like q, gl, hl, location, and device.

Which search engines can I use?

The plugin repository lists Google, Bing, Yandex, and DuckDuckGo actions, including several Google and Bing vertical search actions such as images, news, shopping, maps, and videos.

What is the difference between google_search and raw_serp_request?

Use google_search when you want a normal Google Search action with common parameters exposed in Dify. Use raw_serp_request when you need advanced engine-specific parameters through a custom params_json object.

Can I use it for RAG?

Yes. A common pattern is to use the SERP tool to retrieve fresh search results, then pass snippets, titles, and URLs into an LLM node or combine them with an internal knowledge base.

Should every Dify workflow use search?

No. Search is useful when answers depend on fresh or external information. For stable definitions, internal workflows, or purely user-provided content, search may be unnecessary.