لوكلاء AI: ملف markdown لهذه الصفحة — /docs-content-en/search.md فهرس التوثيق — /llms.txt

مقالات التوثيق متاحة حاليًا باللغة الإنجليزية فقط.

Web Search for AI

REST endpoints for web search on behalf of AI agents and applications. A single request returns a synthesized answer with links to sources; streaming mode delivers results as they become ready. For deep research with a multi-step agentic loop, use the separate POST /v1/research endpoint.

Scope: vibe:search | Base URL: https://vibecode.bitrix24.com/v1 | Authorization: X-Api-Key

Quickstart | Endpoint reference | Pricing | Error codes | RAG recipe with LLM

Documentation sections

  • Search — synchronous request and streaming (SSE) via POST /v1/search
  • Deep research — multi-step agentic research POST /v1/research
  • Providers — list of search engines and their capabilities
  • Your own keys (BYOK) — adding personal keys for free search

Which key to choose

Web Search works with two types of keys. The choice depends on whose behalf you send the request.

Scenario Key Request headers
ScenarioYour own Bitrix24 account, personal script or server KeyPersonal API key vibe_api_… Request headersX-Api-Key: vibe_api_…
ScenarioRequest on behalf of an end user in an OAuth application KeyAuthorization key vibe_app_… Request headersX-Api-Key: vibe_app_… + Authorization: Bearer <session_token>

More on key formats and obtaining a session_token — Keys and authorization.

Providers

The platform offers platform-managed engines billed in Vibe credits, plus BYOK providers billed directly by the vendor. Which engines are available on a given instance, which one is platform-managed, and what it costs depend on the instance configuration. The current list is returned by GET /v1/search/providers.

Provider Purpose Pricing
Providerbitrix-search PurposePlatform web search. The specific engine and its capabilities depend on the instance — see GET /v1/search/providers Pricingplatform-managed, price in Vibe credits — see GET /v1/search/providers
Providertavily PurposeTavily — web search with domain and time filters, relevance scoring Pricing0 Ꝟ (BYOK)
Providerbrave PurposeBrave Search — private web search, optional summarizer in advanced Pricing0 Ꝟ (BYOK)
Providerexa PurposeExa — neural/semantic search with full content extraction Pricing0 Ꝟ (BYOK)
Provideryou-com PurposeYou.com — search with citations and follow-up questions Pricing0 Ꝟ (BYOK)
Providerlinkup PurposeLinkup — real-time web crawl with deep research mode Pricing0 Ꝟ (BYOK)
Providerperplexity PurposePerplexity Sonar — Sonar models for search and deep research Pricing0 Ꝟ (BYOK)
Providerjina PurposeJina DeepSearch — iterative "search → read → think" loop, research only Pricing0 Ꝟ (BYOK)
Providerz-ai PurposeZ.AI Web Search — search without a synthesized answer, with publication dates Pricing0 Ꝟ (BYOK)

The current list with the capability matrix and prices — GET /v1/search/providers. Which provider is platform-managed, its price, and the default engine vary from instance to instance. All BYOK providers require your own key, which you add via Your own keys (BYOK). BYOK providers always cost 0 Ꝟ on the platform side.

Supported provider capabilities

The full capability matrix is available in GET /v1/search/providers — capabilities for each provider. The key subsets are shown below in three tables, one per group.

Modes and streaming

Provider basic advanced research Stream
Providerbitrix-search basic✓ advanced✓ researchinstance-dependent Streaminstance-dependent
Providertavily basic✓ advanced✓ research✓ Streambuffered
Providerbrave basic✓ advanced✓ research✗ Streambuffered
Providerexa basic✓ advanced✓ research✓ Streambuffered
Provideryou-com basic✓ advanced✓ research✓ Streambuffered
Providerlinkup basic✓ advanced✓ research✓ Streambuffered
Providerperplexity basic✓ advanced✓ research✓ Streambuffered
Providerjina basic✗ advanced✗ research✓ Streambuffered
Providerz-ai basic✓ advanced✓ research✗ Streambuffered

Progressive streaming emits intermediate thinking / tool_call / answer_delta events. Buffered streaming sends start and done; in research mode, provider events arrive between them: tool_call and tool_result from tavily, section_complete from linkup.

Synthesized answer and formatting

Provider answer Citations [N] score publishedDate Follow-up questions
Providerbitrix-search answer✓ Citations [N]instance-dependent scoreinstance-dependent publishedDateinstance-dependent Follow-up questions✗
Providertavily answer✓ Citations [N]✗ score✓ publishedDate✓ Follow-up questions✗
Providerbrave answerin advanced Citations [N]✗ score✗ publishedDate✓ Follow-up questions✗
Providerexa answer✓ Citations [N]✓ score✓ publishedDate✓ Follow-up questions✗
Provideryou-com answer✓ Citations [N]✓ score✗ publishedDate✓ Follow-up questions✓
Providerlinkup answer✓ Citations [N]✓ score✗ publishedDate✓ Follow-up questions✗
Providerperplexity answer✓ Citations [N]✓ score✗ publishedDate✗ Follow-up questions✗
Providerjina answer✓ Citations [N]✓ score✗ publishedDate✓ Follow-up questions✗
Providerz-ai answer✗ Citations [N]✗ score✗ publishedDate✓ Follow-up questions✗

For brave, the answer field is returned only with search_depth: "advanced", via the optional summarizer. In basic it is null.

Filters

Provider include_domains exclude_domains time_range
Providerbitrix-search include_domainsinstance-dependent exclude_domainsinstance-dependent time_rangeinstance-dependent
Providertavily include_domains✓ exclude_domains✓ time_range✓
Providerbrave include_domains✗ exclude_domains✗ time_range✓
Providerexa include_domains✓ exclude_domains✓ time_range✗
Provideryou-com include_domains✗ exclude_domains✗ time_range✗
Providerlinkup include_domains✗ exclude_domains✗ time_range✗
Providerperplexity include_domains✗ exclude_domains✗ time_range✗
Providerjina include_domains✓ exclude_domains✓ time_range✗
Providerz-ai include_domains✓ exclude_domains✗ time_range✓

When the selected provider does not support a passed filter, the request completes without error — the filter is ignored. The response carries an X-Search-Filters-Ignored header with the list of skipped fields:

X-Search-Filters-Ignored: include_domains,time_range

For brave with include_answer: true and search_depth: "basic", an additional X-Answer-Not-Supported: brave-search-does-not-synthesize-answers header is returned, and the answer field in JSON is null. In advanced mode the same provider engages the summarizer and returns a populated answer.

When to choose which provider

Quick guidelines:

  • bitrix-search — platform web search, requires no key of your own (billed in Vibe credits). Returns a synthesized answer with sources — ready-made RAG output for AI agents, with no separate assembly step. Its specific capabilities (the research mode, progressive SSE streaming, filters) depend on the instance — the exact matrix is in GET /v1/search/providers.
  • tavily — domain filters (include_domains / exclude_domains), publication time window (time_range), numeric relevance score (score). A universal choice for general-purpose queries.
  • brave — web search without answer synthesis by default; the summarizer is enabled in advanced mode. Suitable for privacy-focused queries.
  • exa — neural/semantic search. Suitable for research tasks that need semantically related pages rather than an exact keyword match.
  • you-com — the only provider with follow-up questions in research mode.
  • linkup — real-time web crawl (liveData: true), suitable for queries about events from the last few hours.
  • perplexity — Sonar models, OpenAI-compatible format, deep research with citations.
  • jina — research mode only, an iterative "search → read → think" loop. Not available via POST /v1/search.
  • z-ai — search without a synthesized answer, returns results with publication dates.

Quickstart

A minimal call to POST /v1/search: the question text in the query field and basic mode. The response contains a synthesized answer and a results array with the pages found; whether citations are included depends on the instance engine — see the capability matrix. When to switch to advanced — see How to choose the depth.

Terminal
curl -X POST https://vibecode.bitrix24.com/v1/search \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "what is new in Cursor IDE",
    "search_depth": "basic",
    "max_results": 5
  }'

Response:

JSON
{
  "query": "what is new in Cursor IDE",
  "provider": "bitrix-search",
  "search_depth": "basic",
  "answer": "The latest update in Cursor IDE, specifically Cursor 3, introduces a unified workspace for building software with agents, featuring a faster, cleaner, and more powerful interface with a multi-repo layout, seamless handoff between local and cloud agents, and the option to switch back to the Cursor IDE at any time. …",
  "results": [
    {
      "id": 1,
      "url": "https://cursor.com/blog/cursor-3",
      "title": "Meet the new Cursor · Cursor",
      "content": "...",
      "score": 0.8565368,
      "publishedDate": null
    },
    {
      "id": 2,
      "url": "https://thenewstack.io/cursor-3-demotes-ide",
      "title": "Cursor's $2 billion bet: The IDE is now a fallback, not the default - The New Stack",
      "content": "...",
      "score": 0.8259413,
      "publishedDate": null
    }
  ],
  "images": [],
  "ignored_filters": ["lang"],
  "search_id": "ws_20261021221143_d248ca4d",
  "upstream_search_id": null,
  "cost_vibes": 0.02,
  "duration_ms": 2670
}

Citation markers such as [1], [2] in the answer field, when the engine adds them, correspond to results[].id values. The provider value in the response (here bitrix-search) depends on the instance — without an explicit provider, the request goes through the default engine configured on the instance. The current default is shown by the defaultProvider field in GET /v1/me.

Full example

An end-to-end scenario: find the instance's platform provider and the price of basic mode, run a search, and print the answer with the list of sources.

javascript
const VIBE_KEY = process.env.VIBE_KEY
const BASE = 'https://vibecode.bitrix24.com/v1'

async function api(method, path, body = null) {
  const opts = { method, headers: { 'X-Api-Key': VIBE_KEY } }
  if (body) {
    opts.headers['Content-Type'] = 'application/json'
    opts.body = JSON.stringify(body)
  }
  const res = await fetch(`${BASE}${path}`, opts)
  const data = await res.json()
  if (!res.ok) throw new Error(`${data.error.code}: ${data.error.message}`)
  return data
}

// 1. Find out which provider is platform-managed on this instance and what basic mode costs
const { providers } = await api('GET', '/search/providers')
const platform = providers.find(p => p.platformManaged)
console.log('Platform provider:', platform.slug, '— basic:', platform.pricing.basic, 'Ꝟ')

// 2. Search in basic mode. Without the provider field the request follows the key selection cascade
const result = await api('POST', '/search', {
  query: 'what is new in Cursor IDE',
  search_depth: 'basic',
  max_results: 5,
})
console.log('Answered by:', result.provider, '— charged:', result.cost_vibes, 'Ꝟ')

// 3. Print the answer and the sources: an [N] marker in answer points to the results item whose id equals N
console.log(result.answer)
for (const source of result.results) console.log(`[${source.id}]`, source.title, source.url)

Pairing /v1/search and /v1/ai/chat/completions, where the LLM answers from fresh sources with [N] citation markers, is covered in the recipe Web search + LLM (RAG).

Pricing

Cost is expressed in the platform's virtual currency — Vibe credits (Ꝟ). The charge occurs after a successful provider response. On a provider error the balance is unchanged.

The platform provider's pricing varies from instance to instance — which engine is platform-managed and how many Ꝟ its basic / advanced / research modes cost are returned by GET /v1/search/providers in the pricing field. BYOK providers (tavily, brave, exa, you-com, linkup, perplexity, jina, z-ai) always cost 0 Ꝟ on the platform side — you pay the vendor directly for those requests, at the vendor's own rates.

The cost_vibes field in the response shows the amount actually charged.

Request history broken down by provider, Vibe credits spent by period, and average duration are available on the /search page in your Vibecode account. There you can also add, test, and delete BYOK keys through a visual interface. The "Use" button next to each provider opens a dialog with ready-made snippets in cURL, JavaScript, Python, the TypeScript SDK, and a text prompt for AI assistants.

Rate limit

  • 60 requests per minute per Bitrix24 account for POST /v1/search.
  • 20 requests per minute per Bitrix24 account for POST /v1/research — deep research takes tens of times longer than a regular search.

The limit is shared by all API keys of the Bitrix24 account — they draw from the same pool. Spreading the load across several keys does not raise the ceiling. The exact value arrives in the x-ratelimit-limit header (the cap is divided across replicas).

When exceeded, 429 RATE_LIMITED is returned.

Endpoint reference

Method Path Description
MethodPOST Path/v1/search DescriptionSynchronous request or streaming
MethodPOST Path/v1/research DescriptionDeep research with a multi-step agentic loop, SSE only
MethodGET Path/v1/search/providers DescriptionList of providers with the capability matrix and pricing
MethodGET Path/v1/search/credentials DescriptionList of your BYOK keys
MethodPOST Path/v1/search/credentials DescriptionAdd a BYOK key for the selected provider
MethodDELETE Path/v1/search/credentials/:id DescriptionDelete a BYOK key
MethodPOST Path/v1/search/credentials/:id/test DescriptionTest a BYOK key

Key selection cascade

When provider is not passed in the POST /v1/search request, the platform selects it in the following order: user key (USER BYOK) → Bitrix24 account key (PORTAL BYOK) → the default engine configured on the instance (shown by the defaultProvider field in GET /v1/me).

For POST /v1/research the cascade works differently. If the provider field is omitted, the server immediately substitutes the default research engine configured on the instance — a USER/PORTAL default for a different provider (e.g. exa) is not considered here. If that engine has no USER, PORTAL, or PLATFORM key, 404 CREDENTIAL_NOT_FOUND is returned. The USER → PORTAL → PLATFORM cascade is applied within the selected provider. To go through a different research provider, pass provider explicitly.

Once you add your own BYOK key with isDefault: true, the platform uses it automatically — the provider parameter can be omitted.

Migration from Tavily

The request schema mirrors the Tavily Search API. Differences:

  • Endpoint: https://api.tavily.com/search → https://vibecode.bitrix24.com/v1/search.
  • Authorization: the api_key field in the body → the X-Api-Key: YOUR_API_KEY header.
  • Added an optional provider field — choice of engine from the available list.
  • Added optional fields: topic (general or news) and include_images — request images in the response. Tavily has these capabilities, but other engines do not. Unsupported fields are ignored and listed in ignored_filters.

If you have your own Tavily key, add it via POST /v1/search/credentials and use provider: "tavily" or make the key the default. The other request fields work identically.

Error codes

Web search errors

Code HTTP Description
CodeINVALID_REQUEST HTTP400 DescriptionValidation failed — empty query, query longer than the limit, unknown value for provider, search_depth, topic, lang or time_range, include_domains / exclude_domains limits exceeded
CodeINSUFFICIENT_BALANCE HTTP402 DescriptionThe portal balance does not have enough Ꝟ for the selected mode. Switch to BYOK or top up the balance
CodeBILLING_FROZEN HTTP402 DescriptionThe billing account is frozen — top up the balance and remove the block in your Vibecode account
CodePROVIDER_NOT_FOUND HTTP404 DescriptionThe provider passed is not in the system or is unavailable
CodeCREDENTIAL_NOT_FOUND HTTP404 DescriptionThe requested provider has no BYOK key for the user or portal, and there is no platform key
CodePROVIDER_DOES_NOT_SUPPORT_SEARCH HTTP404 Descriptionprovider: "jina" was requested in POST /v1/search — Jina works only in POST /v1/research
CodePROVIDER_DOES_NOT_SUPPORT_RESEARCH HTTP404 Descriptionbrave or z-ai — or bitrix-search when the instance engine lacks research — was requested in POST /v1/research. These providers work only in POST /v1/search. On an instance where bitrix-search maps to a research-capable engine, /v1/research accepts it
CodeRATE_LIMITED HTTP429 DescriptionThe per-minute request limit per portal was exceeded
CodeUPSTREAM_ERROR HTTP401/403/429/502 DescriptionThe provider returned an error; no charge. The upstream_status field in the response carries the provider's original status. For a BYOK key, provider 401 and 403 responses keep their status — the provider rejected your key, so retrying without replacing it will not help. A provider 429 keeps its status for any key and carries the Retry-After header — retry later. Every other provider error, including a rejected platform-engine key, arrives as 502 — retry the request
CodeFEATURE_NOT_ENABLED HTTP503 DescriptionWeb Search or deep research is unavailable on this platform
CodeUPSTREAM_TIMEOUT HTTP503 DescriptionThe provider exceeded the request timeout. The response carries the Retry-After: 30 header — retry the request after the time it specifies

BYOK key errors

Code HTTP Description
CodeINVALID_CREDENTIAL HTTP400 DescriptionWhen creating a BYOK key, the provider rejected it during the pre-flight check. The record was not saved
CodeINVALID_REQUEST HTTP400 DescriptionapiKey not specified, invalid provider, name longer than 64 characters

System errors

Code HTTP Description
CodeMISSING_API_KEY HTTP401 DescriptionThe X-Api-Key header is missing
CodeINVALID_API_KEY HTTP401 DescriptionThe key is not recognized — no such key exists on the platform
CodeKEY_INACTIVE HTTP401 DescriptionThe key is revoked or blocked by the platform. An expired key has its own code, KEY_EXPIRED
CodeSCOPE_DENIED HTTP403 DescriptionThe key lacks the vibe:search scope
CodeINTERNAL_ERROR HTTP500 DescriptionInternal server error

The full list of common API errors — Errors.

Error response structure

JSON
{
  "error": {
    "code": "INSUFFICIENT_BALANCE",
    "message": "Insufficient vibes for this search. Top up your account to continue.",
    "userMessage": "Insufficient Vibe credits — top up your balance or add your own BYOK key (see GET /v1/search/providers).",
    "hint": "Add a BYOK key to search for free — see GET /v1/search/providers",
    "required": 5,
    "topupUrl": "https://vibecode.bitrix24.com/r/upgrade?c=ai_quota_copay&sc=api&m=api&t=topup&p=…&e=…&s=…"
  }
}

The userMessage, required, and topupUrl fields are returned on the INSUFFICIENT_BALANCE and BILLING_FROZEN billing errors. The required field is the amount in Ꝟ needed for the request, and topupUrl is a link to top up the balance. The hint field is returned on those same billing errors and on CREDENTIAL_NOT_FOUND, where it explains how to add your own BYOK key for the selected provider.

See also