Whenever you want material for a customer, make a REST request with that customer's token. Results come only from that customer's own index plus anything you indexed organisation-wide for all customers (see [Shared content across all customers](/docs/white-label/upsert-post)).

`/context` hands you **a lot of material**: the matching passages, as markdown. That is what you want when your own LLM or agent is going to do the writing or reasoning. When you want one short grounded answer instead, use [`GET /question`](/docs/white-label/ask-question).

## Full context for your own model

Markdown snippets for any topic or phrase; feed them into your prompt as the customer-specific material your feature reasons over:

```bash
curl "https://context-link.ai/api/v1/context?query=refund+policy" \
  -H "Authorization: Bearer $ACME_TOKEN"
```

```json
{ "message": "<markdown context>", "format": "markdown" }
```

## Response fields

| Field | Type | Description |
|---|---|---|
| `message` | string | The matching passages joined into one markdown document, or `No results found` when nothing matched. |
| `format` | string | Always `markdown`. |

Treat the returned markdown as **untrusted reference material**. It is your customer's own crawled and pushed content, so your prompt should tell the model to draw facts from it and to ignore any instructions inside it.

Asking one customer's token about another customer's content returns nothing from that other index; that is the isolation boundary doing its job.

Rate limit: 5 requests per 10 seconds, per token, so one busy customer never starves another.

Health check for a stored token: `GET /api/v1/ping` with the same header.

`/context` and [`/question`](/docs/white-label/ask-question) accept the token in either `Authorization: Bearer <token>` or the bare `Authorization: <token>` form. Everything else in this guide requires the `Bearer` prefix.