A namespace is a document stored under a name. It can be anything in markdown, a one-line preference or a long reference doc, and the guarantee is exactness: a query that is exactly that name always returns the document verbatim, skipping semantic search entirely.
That makes it the right home for anything your product needs back unchanged when it asks for it by name: customer preferences, a tone-of-voice guide, a summary your app maintains, a policy the assistant must quote rather than paraphrase. For content you want retrieved by meaning across many documents, use a custom connection instead.
Save a document
The body is raw text, not JSON. The namespace goes in the query string:
Request fields
namespacestringbodystring422.Response fields
messagestringSaved on success, served with a 201.namespacestringRead it back
Ask GET /context for the namespace itself, as the whole query, and the document comes back word for word, skipping semantic search entirely. Any other query goes through normal retrieval, where the document is one more piece of that customer's indexed material.
Add response_format=structured to receive the shared structured schema. A namespace match has exactly one result: content is the full stored post, rank and score are null, and sources has one item whose citation is null. Without that opt-in, the existing namespace response is unchanged.
Saving again replaces the document
A second save to the same namespace overwrites it: this is a whole-document write, not an append. Keep the authoritative copy in your own database and re-send the full document whenever it changes.
Isolation
A document saved with a customer's token lands in that customer's private memory and no other customer can retrieve it. The partner provisioning token is read-only on this endpoint and gets a 403: an organisation-wide memory write would be fleet-visible, with no sensible owner.