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
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. |
Both endpoints accept response_format=structured for the same citation-ready schema: top-level format, query, markdown and results; each result has content, position, rank, score, content_sha and sources; and each source has citation, uid, title, url, source_updated_at and connection. /context returns many chunk results with one source each, while /question returns zero or one answer result with its cited sources. Without that opt-in, each endpoint's existing default response remains unchanged.
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.
What a customer's context can be made of
Three sources of content, and they stack:
| Source | How it gets there |
|---|---|
| Their website | Given as site_url when you provision the account. Crawled for you. |
| What your product knows | Pushed as markdown through the Custom Connections API: dashboards, CRM notes, anything not on a public page. |
| Their own connected sources | Their mailbox, Drive, OneDrive, Notion, Basecamp, YouTube channel or another website, connected from inside your product with a uid you choose. |
The third one is connected over the API like everything else: your customer consents at the provider under your brand, and never sees Context Link. You choose which types to offer at /white_label/connection_activations, where the OAuth sources also need your own OAuth client, with our redirect URI whitelisted on it, before they turn on. Google Drive can instead run on Context Link's verified Google app, with Context Link named on the consent screen.
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.