RAG White-Label API | Context Link
You are building a product whose features get better the more they know about each customer: their website, their documentation, the data they push through your product. Thousands of pages of it, different for every account.
The RAG White-Label plan gives you search by meaning over each user's own context, so your features can draw on it. Say you ship a blog-post outlining feature: before it writes anything, it can ask that user's context about the things the post mentions (their features, their positioning, the opinions they have already published) and produce an outline that is actually theirs. Not the generic answer every other customer of every other tool gets. Personalisation through the customer's own context, rather than a cleverer prompt.
Watch the intro
Add RAG to Your SaaS - personalise your AI responses - YouTube
Add RAG to your SaaS: what an isolated index per end-customer gets you, and how the two query endpoints fit into your product. Also on YouTube.
The supporting half is that you don't have to build any of the machinery: no retrieval, chunking, embedding, crawling or grounded answering. You hold many isolated end-customer indexes inside one Context Link organisation, provision them programmatically, and pay for them in bundles that scale with your customer count.
Everything your end customers touch is server-to-server. They never see Context Link: no UI, no emails, no branding. No token ever reaches a browser.
You still get a UI: an API accounts area inside Context Link that shows the fleet you provisioned and every query it has run.
Two ways to read a user's context
| Endpoint | Reach for it when |
|---|---|
GET /context |
You want a lot of material. It returns the matching passages as markdown: rich raw input for your own LLM or agent to work from. |
GET /question |
You want a concise, grounded answer. One short paragraph plus citations: right for showing directly in your UI, and for protecting an agent's context window instead of dumping the user's full context into it. |
Each has its own endpoint: GET /context and GET /question.
There is a third, cheaper signpost that needs no query at all: every account carries a top_level_context paragraph describing who that customer is, written automatically once their index has content. Read it off the account's status when you want to personalise a screen without asking a question first.
Two credentials, different jobs
| Credential | Scope | Where it comes from |
|---|---|---|
| Partner provisioning token | One per partner organisation. Manages the fleet (create / list / status / delete / re-sync API accounts) and can query across all your customers at once. | Settings → Partner provisioning token |
| Per-customer token | One per user account. Both authenticates and identifies that customer: querying and pushing content both use it. | Returned when the API account is created (and again on an idempotent re-POST of the same uid) |
Store uid + token per customer, plus a CONN_ID if you push content. All captured at signup time.
The provisioning token is the high-privilege path. The same secret manages the whole fleet, reads every customer's index, and can permanently delete any of them along with all of its content. Keep it in your core backend only: never in a per-customer context, never in a browser.
Quick reference
| Property | Value |
|---|---|
| Base URL | https://context-link.ai/api/v1 |
| Authentication | Authorization: Bearer <token> |
| Format | JSON in, JSON out |
| Write rate limit | 5 requests per 10 seconds (per user and per organisation) on POST / DELETE / resync |
| Query rate limits | 5 per 10s on /context, 2 per 10s on /question, per token, so one busy customer never starves another |
| Billing | $50/month per bundle of 10 API accounts. Bundles are added automatically on overflow. |
| Crawl cap | 500 pages per API account website |
How the rest of this guide is laid out
The pages in the left sidebar follow the order you will build in: get your token, provision a customer, wait for their index, query on their behalf, push extra content, and clean up when they churn. The reference pages at the end carry the full status-code and limit tables.