ForHosting KIT · Semantic Search & RAG

Index your text

Running a vector database well means picking a chunking strategy, an embedding model, an index type and a hosting bill before a single search query ever runs. This endpoint skips that setup entirely: send text, get a searchable index, and query it whenever you need to.

● StablePer request + per 1,000 chunks$0.002

Run — $0.002 + $0.0015/1,000 chunks How it works & API

Use it from WebAPIEmailApp soonTelegram soon

Run it online

Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.

What running your own vector database actually involves

A working semantic search stack needs at least four decisions made correctly: how to split long text into chunks, which embedding model to use, which index structure to store vectors in, and how to keep that index available and backed up. Most teams that need semantic search don't want to own any of that infrastructure — they want a place to send text and a place to send queries. search.index_text is built for exactly that gap.

What happens between submission and a searchable index

POST /search/index-text with your content, receive a task_id, and get confirmation by webhook or a signed 24-hour link once the text has been split into fragments, embedded, and written into an index tied to your account. From that point on, the content is queryable through the search endpoints without you touching a single vector directly.

Why chunking is the quiet, decisive step

How text gets split matters more than most people expect: a chunk that's too large dilutes the specific meaning a query is looking for, and a chunk that's too small loses the surrounding context that gives it meaning at all. This is the same tension that document retrieval systems have wrestled with since long before embeddings existed, going back to how libraries and early full-text search engines had to decide what counted as a retrievable unit — a page, a paragraph, a section.

What stays under your control

You choose what to send and when to send it; the index itself lives on our side and is queried through the search API rather than through a database connection you manage. If you'd rather own the vectors directly — for a custom index, a data warehouse, or a model you're training — search.embed or search.embed_batch return raw vectors instead of building an index for you.

Where it plugs into a real product

Knowledge-base search, internal documentation search, and RAG context retrieval are the most common uses: index the source material once, then query it per user request. A support team indexes its help articles and FAQ text so a chat assistant can pull the right passage instead of guessing. Billing runs per request plus per 1000 fragments, so indexing a short FAQ and indexing years of internal documentation both cost exactly what they use, nothing assumed in advance.

What you can do with it

Internal knowledge-base search

A company indexes its internal wiki text so employees can search by meaning instead of guessing the exact phrase a page uses.

RAG context store for a chat assistant

A product team indexes its help center articles so a support chatbot retrieves the right passage before an LLM drafts a reply.

Searchable notes and transcripts

A research team indexes meeting transcripts and notes so anyone can later search for what was discussed on a topic across months of records.

Content deduplication check

A publisher indexes drafts before release to search for near-duplicate passages against previously published articles.

FAQ

How do I index text for search with the API?

Send your text to POST /search/index-text, store the returned task_id, and get confirmation the content is indexed by webhook or a signed link valid for 24 hours.

Is the text indexing API free?

No, there's no free tier or trial; it costs $0.010 per request plus $0.002 per 1000 fragments, and a failed task is never charged.

Do I need to run my own vector database?

No, that's the point of this endpoint: chunking, embedding and storage all happen on our side, and you query the content through the search API.

How is text split into fragments?

Content is automatically chunked into fragments sized to preserve context while staying specific enough for accurate retrieval; you don't need to pre-split it yourself.

What's the difference between this and search.embed?

search.embed returns a raw vector for you to store; search.index_text handles chunking, embedding and storage together and gives you a ready-to-query index instead.

Can I update or remove indexed content later?

Yes, check the endpoint reference for update and deletion operations against an existing index entry.

Can I index large volumes of text at once?

Yes, and for indexing many separate documents in one job it's usually more efficient to batch the submissions rather than sending them one at a time.

Is my indexed text used to train any model?

No, indexed content is deleted after the retention window and is never used for training.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/search/index-text

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/search/index-text \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"text":"…"}'

const res = await fetch("https://api.kit.forhosting.com/search/index-text", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "text": "…"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/search/index-text",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "text": "…"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/search/index-text", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"text":"…"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"text":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/search/index-text", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "text": "…"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "search.index_text",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Per 1,000 chunks$0.0015

Published price — no tokens, no invented credits. A failed task is never charged.

Limits

`max_chunks`	10000
`max_tokens`	20000

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Read the full KIT documentation →