Skip to main content

Endpoint references

Lifecycle

Why both type=knowledge and app_knowledge? They have a theoretical differentiation.
  • type picks the bucket: knowledge (shared documents) or memory (per-user context). It routes the ingest to the right store.
  • Within type=knowledge, you pick the payload shape: documents (binary documents HydraDB will parse - PDFs, DOCX, CSV) or app_knowledge (a JSON array of already-extracted content from your app - Slack messages, Notion pages, web pages). You can send both in the same request.

Core Ingestion Concepts

  • Knowledge vs. Memories: Knowledge is shared, database-wide content (documents, app pages, Slack messages). Memories are user-specific preferences and conversational traits scoped by collection. Both can be searched together via type: "all" on POST /query.
  • IDs: Unique identifiers returned by /context/ingest. You can assign custom IDs using id in metadata or id in app_knowledge items. Use them for polling status, inspecting content, and deleting context.
  • Metadata Filtering: You can scope queries using metadata (structured fields defined in your database schema) or additional_metadata (free-form per-document JSON). For detailed guidelines on structuring metadata, see the Scoping using metadata guide.
  • Forceful Relations: Relationships between sources can be declared at ingestion time to construct a robust knowledge graph. For more details on the graph layer, see the Context Graphs guide.

Forceful relations and metadata

Forceful relations let you pre-wire document relationships at ingestion time so that relevant documents surface together during retrieval - even before the graph layer discovers connections organically. Think of them as explicit “see also” links between your documents. Paired with document-level metadata, you get deterministic control over how results are filtered and ranked.
Python SDK
Related Resources