Note: All code in this guide is production-ready and uses real HydraDB endpoints. Base URL: https://api.hydradb.com. Get your API key at app.hydradb.com.
Goal: Ingest six source types into one HydraDB tenant, store per-user memory profiles for personalized answers, and answer three query patterns - simple factual lookup, decision provenance, and cross-source synthesis - all through POST /recall/full_recall.
Prerequisites
Required knowledge: Python basics, REST APIs, environment variablesRequired tools:
- HydraDB API key
- Python 3.11 or 3.12 (
python --version) pip install hydradb-sdk
What You’ll Build
By the end of this cookbook, you’ll be able to:- Ingest Slack threads, Gmail, Confluence pages, GitHub issues, and Linear tickets into a single HydraDB tenant
- Answer cross-source questions like “Why did we move to a monorepo?” that span multiple tools and time periods
- Use
recency_biasandgraph_context: trueto surface the most relevant, connected context across all sources - Store per-user memory so answers are personalized to each employee’s role and project context
The Problem with Per-Tool Search
Every company has knowledge scattered across a dozen tools. The answer to “why did we move from microservices to a monorepo?” is split between a Confluence RFC, a Slack thread in #architecture, a GitHub PR discussion, and an email thread between two VPs. No single tool contains the full answer. Keyword search returns one fragment. The person who knows is usually in a meeting. This cookbook builds a company-wide search engine that works like Perplexity - but over your internal knowledge. Ask any question, get a cited answer that synthesizes across Slack, email, docs, code, and project management. The answer includes provenance: where each piece came from and when it was recorded. The critical capability that makes this possible is HydraDB’s context graph. It automatically links entities across tools - “Project X” in a Slack message is connected to “Project X” in a Confluence page, the GitHub repo namedproject-x, and the Linear project tracking it. A query about Project X surfaces all of these together, ranked by relevance and recency, in a single call.
Architecture Overview
- Ingestion Layer: Six connector scripts that format source content and upload to HydraDB via
POST /ingestion/upload_knowledgeusing multipart form-data. - HydraDB: Stores all sources, automatically builds a context graph linking entities across tools, and ranks results by relevance and recency at query time.
- User Memory: Per-user profiles stored via
POST /memories/add_memoryand retrieved viaPOST /recall/recall_preferencesto personalize answer depth and format.
Step 1 - Create Tenant
One tenant for all company knowledge. Usesub_tenant_id to isolate by source type - "slack", "email", "docs", "github". All created automatically on first write, no setup required.
Step 2 - Ingest Company Knowledge
All connectors use the same endpoint:POST /ingestion/upload_knowledge. This endpoint uses multipart form-data - not a raw JSON request. For app connectors, send app_knowledge as a JSON-stringified form field. Each app-source item includes its own id, tenant_id, sub_tenant_id, kind, provider, external_id, fields, and optional metadata, relations, attachments, and comments.
Important: Do not setContent-Type: application/json. Pass onlyAuthorizationin headers and let your HTTP client set the multipart boundary automatically.app_knowledgemust be serialized withJSON.stringify(...)/json.dumps(...)before upload.
Batch limit: Max 20 sources per request. Wait 1 second between batches. Always call POST /ingestion/verify_processing before querying newly ingested content.
The upload response for all connectors looks like this:
results[0].source_id - you need it to verify indexing.
2.1 Slack Channels
Ingest each Slack message as a typedmessage app source. Use thread_id for the root message timestamp and parent_id for replies so HydraDB can expand same-thread context during Recall.
2.2 Gmail / Email Threads
Email threads contain decisions that never make it to Confluence. Ingest each Gmail message as a typedemail app source with thread_id and reply_to_id when available.
2.3 Confluence & Notion
Confluence and Notion pages are structured knowledge-base app sources. Upload each page withkind: "knowledge_base", a provider-scoped external_id, and space/database metadata so HydraDB can preserve hierarchy and citations.
2.4 GitHub Issues & PRs
GitHub issues contain the full discussion trail around engineering decisions - requirements, objections, alternative approaches, and the final resolution. Include all comments so HydraDB can build graph links between issue discussions and Slack threads that mention the same features.Linear connector: Use the Linear GraphQL API (https://api.linear.app/graphql) with your API key. Format each issue + comments as a plain text file withSource: Linearprepended, and upload withsub_tenant_id: "linear". The same multipart upload pattern applies.
Step 3 - Verify Indexing
After uploading, pollPOST /ingestion/verify_processing until indexing_status is completed before running any queries. HydraDB indexes asynchronously - typically 10–30 seconds per file.
Note:verify_processinguses POST withfile_idsandtenant_idas URL query parameters. Pass an empty JSON body{}.
Step 4 - Store User Memory Profiles
Each user gets a persistent memory profile. HydraDB uses it to personalize search results - an engineer gets more technical answers with PR citations, a product manager gets decision context and timelines, a new hire gets more background on why things are built the way they are.Step 5 - Search Interface
Three query patterns cover every internal search use case. All usePOST /recall/full_recall with different parameters. The routing logic is lightweight - keyword detection on the question, not ML classification.
Important: UsePOST /recall/full_recallwith aqueryfield for all three query patterns below. It returns retrieved chunks and graph context; your app can pass that context to an LLM when it needs a synthesized answer.
5.1 Simple Factual Lookup - “What is X?” / “How does X work?”
Use balancedrecency_bias: 0.5 for factual questions where both old and recent context matter equally. Restrict to a sub_tenant_id if the user is clearly asking about a specific tool.
5.2 Decision Provenance - “Why did we decide X?” / “What led to Y?”
For provenance questions, usegraph_context: true and read graph_context.chunk_relations from the response - these are the multi-hop entity chains that trace a decision back through Slack, email, Confluence, and GitHub. Pass the chunks and relation chains to an LLM to synthesize a fully cited answer.
5.3 Cross-Source Synthesis - Complex multi-part questions
For questions that span multiple topics or time periods, usemode: "thinking" with a lower recency_bias to surface both old and recent context. HydraDB decomposes the question into sub-queries automatically and ranks results across all sub-tenants.
Step 6 - Recall User Preferences
To personalize any answer, retrieve the user’s stored memory profile before calling the LLM. This is the same response structure asfull_recall - an array of chunks.
Reading the response:recall_preferencesreturns the same structure asfull_recall. Read the profile fromchunks[0].chunk_content.additional_metadatawill benullfor memory entries - this is expected.
Step 7 - Interfaces
Web API (Flask)
Slack Bot
Step 8 - Incremental Sync
Run a nightly sync to keep all sources current. HydraDB’s upload is idempotent - re-uploading unchanged content with the same filename overwrites cleanly.API Reference
All endpoints used in this cookbook. Base URL:https://api.hydradb.com · Header: Authorization: Bearer YOUR_API_KEY
Create Tenant
Upload Knowledge (form-data)
Do not use Content-Type: application/json. This is a multipart upload.
Verify Processing (URL params + empty body)
Store User Memory
Recall User Preferences
Full Recall - All Sources
Full Recall - Scoped to One Source Type
Benchmarks
Tested across a 2-year company knowledge base: 12 Slack channels, 3 Gmail accounts, 4 Confluence spaces, 6 GitHub repos. 400 questions rated by employees across engineering, product, and operations.The 183% improvement on decision provenance reflects HydraDB’s context graph. Naive RAG treats a Slack thread, a Confluence page, and a GitHub issue as three isolated vectors. HydraDB understands they are three pieces of the same decision trail - entity-linked across sources - and surfaces all three together with the relationship chain that connects them.
Benchmark methodology: Figures are based on internal HydraDB testing. See research.hydradb.com/hydradb.pdf for the full methodology. Results will vary by corpus size, content quality, and query distribution.
File Structure
Requirements
Next Steps
- Run
setup.pyto create your tenant. - Start with one source - ingest a single Slack channel or Confluence space and verify indexing.
- Store profiles for 2–3 users via
memory/profiles.py. - Run
python search/qa.pywith a real question to confirm results. - Wire
search/synthesis.pyintointerfaces/slack_search.pyand deploy the Slack bot. - Schedule
sync/nightly.pyvia cron once the initial ingest is complete.