Vector Stores Quick Start

A Vector Store is a knowledge base you can ask questions in plain language. You put text in — typed, uploaded, or sent by a flow — and HostWebhook splits it into small passages and remembers what each one is about. From then on, “what is the refund policy?” brings back the passages that answer it, not the ones that merely contain the word “refund”. It works from the dashboard, from the Vector Store node in a flow, and as a tool an AI Node can use on its own.

ℹEverything on this page is under Settings → Vector Stores in the dashboard, or inside the Vector Store node on the canvas. No code involved. If you are integrating by API, jump to the Vector Stores API reference.

The five-minute path

Settings → Vector Stores → + New store

The button is greyed out when your plan is at its limit of stores — the usage strip at the top of the page shows where you stand.

Name it and pick a provider and model

Company Docs, Support Playbook. The preselected model (OpenAI text-embedding-3-small) is the right default for almost everyone: cheap and good. See what each field means if you want to know what the small print under each model says.

Pick the API key that will pay for it

Every time content goes in and every time a question is asked, the provider bills your key. Choose an existing credential or add a key right there.

Leave Backend and Chunking as they are — for now

HostWebhook (managed) needs no setup. The chunking defaults are fine for short texts; before you load a manual or a PDF, read Chunking — it is the one setting that decides whether searches find anything.

Create store → Ingest tab → paste or upload → Ingest

A message tells you how many passages were stored. Then open the Query tab and ask a real question. If the first result is the passage you had in mind, the store works.

What each field on the form means

On the screen	What it decides	Can you change it later?
Name / Description	How the store appears in lists — and, when you give it to an AI Node as a tool, the name and the one-line description the model reads to decide whether to search here.	Yes
Provider and Model	Who turns your text into something searchable, and how well. The small print under each model: dims is a size you never have to think about, tokens is the longest single passage it accepts, and the price is per million tokens of text processed. The larger model matches a bit better and costs about six times more.	No
Credential	Which API key gets billed — on ingest and on every question.	Yes, to another key of the same provider
Backend	Where the passages are kept. HostWebhook (managed) is ours and counts against your plan; MongoDB Atlas and PostgreSQL are your own database, with no quota.	No
Chunking	How the text is split into passages before it is stored. See Chunking.	Yes — for what you add from then on
Strict scan mode	Whether an uploaded file waits for the malware check to come back clean before it is stored. On by default; leave it on for any store an AI agent reads.	Yes, immediately

⚠Provider, model and backend show an Immutable badge on the store page for a reason: everything already stored was processed with those settings, and passages processed by two different models cannot be compared. To switch models, create a second store and load the content again.

Both bring-your-own backends have a Test connection button that tells you what is missing and, on PostgreSQL, an Auto-setup button that creates it for you. Step by step guides: Bring your own MongoDB, Bring your own PostgreSQL, and, for a database that is not reachable from the internet, Reverse tunnel for databases. A model marked Coming soon cannot be picked yet on the managed backend; on your own database it works.

Chunking — how your content gets split

A store does not remember documents; it remembers passages (chunks). Every search returns passages, so the size of a chunk is the size of the answer you get back. Cut too small and a passage ends mid-thought; cut too big and the interesting sentence is buried in a page of unrelated text.

Setting	Means
Strategy	Recursive cuts where the text already breaks: paragraph first, then line, then sentence. Use it for anything a person wrote. Fixed cuts every N characters regardless — only for content with no natural breaks, like a log dump.
Size	How long each passage is, in characters. 500 is about a hundred words. Between 50 and 8,000.
Overlap	How many characters two neighbouring passages share, so a sentence that straddles the cut still shows up whole. Roughly a tenth of the size; always smaller than the size.

⚠Size is in characters, not tokens. Most advice on the internet is written in tokens. If a guide says “800 tokens”, type about 3200 here. This is the most common reason a store “never finds anything”: with the default 500, a two-thousand-character section becomes four fragments and none of them holds the whole idea.

What we recommend, by type of content

Start from the row that looks like your content. The store detects the type of what you paste (JSON, CSV, Markdown, code, or plain prose) and splits it in a way that respects its structure; the numbers below are the sizes that work well with that.

Content	Strategy	Size	Overlap	Why
Plain text — emails, articles, policies, help center	Recursive	1000 – 1500	100 – 150	One or two paragraphs per passage: enough to hold a complete point, short enough that the point is what the passage is about.
PDF — manuals, contracts, reports	Recursive	1500 – 2000	200	PDFs come out as text without their layout, so a clause or a table row often spans lines. Bigger passages keep it together. For a very long PDF, cap what is read with Max chars per file in the node's Advanced tab.
Markdown — documentation, READMEs, notes	Recursive	1200	100	Headings are respected, so each passage tends to be one section. Upload the file as `.md`, not `.txt`: a `.txt` is treated as plain text and loses that.
JSON — records, exports, product catalogues	—	2000 – 4000 per chunk	—	JSON is split by its own structure — one item of a list, or one key of an object, per passage — so the store's Size does not apply. The limit that does is Max chars per chunk under JSON in the Vector Store node's Advanced tab.
CSV — tables, spreadsheets exported as CSV	—	20 – 50 rows	—	Split by rows, with the header repeated on every passage so each one reads on its own. The rows-per-chunk setting is in the node's Advanced tab under CSV. Fewer rows when each row is long.
Code	Recursive	800 – 1200	100	Cuts land between functions and blocks rather than in the middle of one.
Short pieces — FAQs, chat transcripts, product blurbs	Recursive	400 – 600	50	One question and its answer per passage. This is where the default (500 / 50) is exactly right.

✦Not sure? Load one document, open the Content tab and read three or four passages. If they end mid-sentence, raise Size. If each passage covers several unrelated topics, lower it. That check takes a minute and beats any rule of thumb.

⚠Changing chunking does not re-split what is already stored. It applies to what you add from now on. Loading the same document again does not replace the old passages either — identical text is skipped, different text is added next to it. To re-split a document: remove it first (Content tab, or a Vector Store node in Delete mode with its source doc id), then load it again. To start a store over, use Flush.

Adding content by hand

The Ingest tab of a store takes a file, a block of text, or both.

File — PDF, CSV, JSON and any text file. Images and other binaries are not accepted. Word and Excel files need converting first: a File Transform node in a flow does it.
Text — paste anything. The counter under the box estimates how many passages it will become.
Source doc name — the label people will see: in the Content tab, and next to every search result.
Source doc id — what identifies this document for you: a URL, a page id, a file id. It is how you remove or replace the document later without touching the rest.

✦Give every document a source doc id from the start. Without one, the only ways to remove an outdated document are deleting its passages one by one in the Content tab, or flushing the whole store.

The other tabs

Content — every passage, fifty at a time, filterable by document name or by a word inside the passage. Click a row to read it whole; delete a bad one from its row. This is where you check what the splitting actually produced.
Query — a playground. Type a question, choose how many results, and look at the score next to each. Scores go from 0 to 1: above 0.8 is a confident match, 0.6 to 0.8 is plausible, below that is usually noise.
Audit — who did what to this store and when: created, changed, loaded, searched, deleted.

Pause, flush, delete

Button	What stays	Use it when
Pause	Everything. You can resume any time.	You want to stop spending without losing the content. While paused, nodes and tools that use the store fail.
Flush	The store and its settings. Every passage is gone.	You changed chunking and want to load everything again from scratch.
Delete	Nothing.	The store is no longer needed. Any Vector Store node or AI tool pointing at it stops working and says so when you open it.

What your plan allows

The usage strip at the top of Settings → Vector Stores shows all of this live.

Limit	Free	Pro	Enterprise
Stores	1	10	20
Passages on the managed backend	10,000	1,000,000	2,000,000
Stores on your own database	1	5	10
Managed storage, whole organization	5 MB	5 MB	5 MB

ℹManaged storage counts the text of your passages (plus the AI Node's built-in memory), shared across the organization. Content kept in your own MongoDB or PostgreSQL does not count at all — that is what the “storage full” message points you to.

Using a store from a flow or an agent

The Vector Store node

Put a Vector Store node on the canvas to load, search or remove content as part of a flow: index a page after scraping it, answer an incoming question with the passages that match, forget a document when the source deletes it. Everything the node shows is described in Vector Store node.

As a tool on an AI Node

On an AI Node, Tools → add a Vector Store turns each store you pick into something the model can search by itself when it decides it needs to. A store called “Company Docs” shows up to the model as query_company_docs, described with the store's own description. You keep four controls:

Default Top K — how many passages come back per search. The model may ask for more, up to 20.
Min score — passages below it never reach the model. The model cannot lower it.
Filter — labels a passage must carry to be found, like tenant: acme. The model never sees it and cannot change it, so it is how you keep an agent on one customer or one topic. Plain values only, and the same in every conversation: it does not fill in {{…}}, so a template there is refused when you save.
Name and description — worth editing: they are all the model reads when deciding whether this store is the place to look.

When something looks wrong

Searches return nothing, or the wrong passages

In this order. Open Content and read a few passages: if they end mid-sentence, they are too small — raise Size, flush, load again. If the passages look fine, ask the same question in Query with no minimum score and look at the numbers: a best score around 0.5 means the store simply does not contain the answer. If a node returns nothing but the Query tab finds it, the difference is almost always a metadata filter or a minimum score set on the node.

I changed the chunk size and the number of passages did not change

Your content is JSON or CSV, which have their own settings in the Vector Store node's Advanced tab — see the table above.

A filter by my own metadata key fails on the managed backend

On the managed backend, searches can only be narrowed by document, not by your own metadata keys yet. If you need to filter by tenant or chapter, use a store on your own PostgreSQL (any key works with no setup), or keep those groups in separate stores.

The New store button is greyed out

Your plan's limit on stores. Delete one you no longer use, or upgrade. The passages counter next to it is a different limit: reaching it blocks loading, not creating.

A model says “Coming soon”

Not available on the managed backend yet. Pick another model, or use your own database, where every model works.

Loading a file stops with a message about scanning

Strict scan mode is on and the file has not been cleared yet. Wait a few seconds and try again. A file the scanner rejects is refused in every mode.

textA store that behaves — quick checklist

[x] every document has a source doc id
[x] chunk Size chosen from the table for your type of content, in characters
[x] Markdown uploaded as .md, not .txt
[x] the Query tab scores above 0.8 for a question you know the answer to
[x] a minimum score is set on the node or the AI tool
[x] a store on your own database was re-tested after any change there

For developers

Everything above can also be done over the REST API — create stores, load content, search, delete by document, browse passages, read the audit log — with the exact request and response shapes documented in the Vector Stores section of the API reference.