For product teams
Ship the answer experience. Skip the year of infrastructure.
Your users want to ask your product a question and get an answer — one that knows both what they are entitled to and how the thing works. Those two facts live in different systems, and between them and an answer sits a pile of infrastructure that has nothing to do with what your product is for.
The alternative
A year of work, none of it your product.
You could build every one of these, and some teams should. The question is whether retrieval quality is what your customers are actually buying from you.
Splitting documents up
Boundaries that do not cut a claim in half — and the discovery, later, that changing your mind about them means reprocessing everything you have ever stored.
Turning text into vectors
A model choice you are stuck with, because moving off it means recomputing every vector in the corpus and paying for all of it again.
A vector store to hold them
Sizing, capacity planning, and a rebuild path for the day it loses a collection — which is the day you find out whether you could rebuild it at all.
Reading facts out of prose
A language model, run over every document, reliably enough that a bad afternoon at the provider does not leave gaps you cannot see. This is where the quality of everything downstream is decided.
Knowing when two things are the same thing
The account in a billing row and the account in a ticket have to become one thing, while several documents are being processed at once. Get it wrong and the graph quietly fills with near-duplicates that no query joins.
A vocabulary that can change
Your content will outgrow whatever categories you started with. Changing them after the fact, without losing what was already stored under the old ones, is a versioning problem most teams meet only once it is expensive.
Writing the answer
Prose that says only what the sources say, citations that resolve to real documents, and a refusal that arrives instead of a plausible invention. The failure here is silent and lands in front of your customer.
Or two endpoints
Ingest and search. No SDK, no framework, no code-level dependency on us.
Getting there
Four steps, and none of them are a migration.
No crawler, no credentials, nothing moved. You send us content and ask us questions.
Push what you already have
One POST per document, keyed on your own identifier. Most teams wire this into whatever already fires when content changes on their side.idempotent — safe to replay
Tag it with a source
Say which system it came from. That is what makes the extraction domain-aware — a billing row is read differently from a runbook — and later it is what tells you which entities appear in more than one of your applications.lms_content · salesforce · zendesk · notion · generic
Search from your product
One POST with the question and, optionally, the prior turns of the conversation. You get ranked passages, a cited answer, and the timings.nothing about the user is stored
Render the citations
Every marker resolves to a document you gave us, so you can link it straight back into your own UI with your own URL scheme.every citation resolves
curl -X POST https://api.graas.ai/v1/ingest \
-H "x-api-key: $GRAAS_KEY" \
-H "content-type: application/json" \
-d '{
"sourceSlug": "billing",
"externalId": "account-4471",
"title": "Account 4471 — Team Annual",
"textContent": "Plan: Team Annual. Seats: 240.
SSO entitlement: false. Renews: 2027-03-01."
}'
# 202 Accepted
# { "documentId": "...", "externalId": "account-4471",
# "status": "extracting", "chunksCreated": 1,
# "statusUrl": "/v1/ingest/.../status" }curl -X POST https://api.graas.ai/v1/search \
-H "x-api-key: $GRAAS_KEY" \
-H "content-type: application/json" \
-d '{ "query": "does onboarding reduce churn?" }'What you ship
Four things teams put in front of users.
All of them the same two calls underneath.
An in-product answer box
A question field that returns prose with footnotes your user can open, rather than ten blue links into your own documentation.
A support copilot
Grounded in your ticket history and your help centre together, so an agent gets the answer plus every previous case that supports it.
An agent tool
Your agent calls search as a tool and gets back cited passages, or connects over MCP and gets the whole surface with one authorisation.
An internal question surface
The thing your team actually needs: one place to ask across the wiki, the tickets and the courses at once.
Why we answer, rather than only retrieve
Otherwise every caller writes the same prompt, worse.
A retrieval API that hands back passages and stops leaves each caller to write their own synthesis prompt over provenance they understand less well than we do — which in practice means grounding that is hoped for rather than enforced, and citations nobody checks.
So the answer comes with the passages. It is written to stay grounded in them, every citation resolves to a document you sent us, and refusal is a real outcome rather than an embarrassing hallucination. If you would rather write your own prompt, the passages are right there and you can ignore ours.
FAQ
Frequently asked
Wire it up on the free tier first.
Fourteen days on the graph tier, 2,500 documents, no card. Enough to put a real answer box in front of a real user before you commit to anything.
- no card required
- first workspace is free
- one POST to ingest