How to Choose the Right Search Source for Your Use Case

Not every search question should use the same source. A docs question, a competitor question, and a research question all need different retrieval choices.

The mistake is to default to one engine and hope it fits everything.

Start with the question, not the engine

Before you search, ask what kind of evidence the user actually needs:

• product documentation
• fresh news
• source code
• papers
• community discussion

Once the evidence type is clear, the source choice becomes much easier.

A simple decision rule

• Use domain when the answer should come from one website.
• Use timeRange when freshness matters.
• Use source-specific engines when the question needs code, papers, or discussion.
• Use a broad web query when you are still exploring the topic.
  See these patterns in action: docs-only support assistant, research assistant for GitHub and arXiv, competitor monitoring.

One API, multiple search styles

curl -X POST https://api.prismfy.io/v1/search \
  -H "Authorization: Bearer ss_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "API key rotation",
    "domain": "docs.yourcompany.com",
    "language": "en",
    "engines": ["brave", "bing"]
  }'

Then compare that with a fresher broad-web query:

curl -X POST https://api.prismfy.io/v1/search \
  -H "Authorization: Bearer ss_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "API key rotation best practices",
    "timeRange": "month",
    "language": "en",
    "engines": ["brave", "bing"]
  }'

How to explain the choice to a developer

The goal is not to teach search theory. The goal is to give a rule they can apply in their app:

1. If the question is about your product, search your docs domain.
2. If the question is about current events, add a freshness window.
3. If the question is about implementation details, use source-specific engines.
4. If the question is unclear, start broad and narrow it later.

Common mistakes

• Reusing the same query shape for every use case.
• Ignoring freshness when the answer changes weekly.
• Searching the open web when the answer should come from one domain.
• Writing a comparison article that never gives a decision rule.

If you want a practical search-source decision rule, start with Prismfy docs and run one POST /v1/search call per use case.