Skip to main content
POST /query returns structured JSON. Before you can pass it to an LLM, you need to convert the retrieval payload into a plain string. This page shows how. The same pattern works regardless of whether you set type: "knowledge", type: "memory", or type: "all" - the response shape is identical.

1. What the response looks like

The SDKs return the full response envelope from POST /query; the retrieval payload is on its data field (e.g. result.data). Raw HTTP responses use the same envelope, with the payload under data. The build_string / buildString helper accepts either the full envelope or just the data payload, so you can pass the SDK return value to it directly. The retrieval payload has the same core shape regardless of type or query_by:
Four things matter for prompt construction:
  • chunks - the primary retrieval output. Ranked by relevance; preserve the order HydraDB returns.
  • graph_context.query_paths - entity traversal paths derived from your query. Useful for relational reasoning. See Context Graphs.
  • graph_context.chunk_relations + chunk_id_to_group_ids - per-chunk graph relations grouped by group_id, so you can attach the right triplets to each chunk.
  • additional_context - a map keyed by chunk_uuid. When a chunk includes extra_context_ids, use those IDs to look up related chunks here.
The raw object has too much noise for an LLM - IDs, timestamps, metadata. Section 2 shows how to convert it into a clean string.

2. Transforming the response into LLM context

Use build_string / buildString from the SDK. It takes any POST /query result and returns a formatted plain string.

3. Feeding the context into your LLM


4. Combining Knowledge and Memories

The simplest path is one POST /query with type: "all" - HydraDB queries both stores in parallel and returns one merged, ranked result set.
If you need to format knowledge and memories in separate labeled sections, call POST /query twice in parallel:
If memory query fails or times out, fall back to the knowledge-only prompt.

5. Practical guidance

  • Preserve server order. Don’t re-sort chunks client-side.
  • Start small on chunks. max_results: 10 is a reasonable default. Drop to 5 if you hit token limits, raise to 20 if you rerank downstream.
  • Use graph context selectively. It improves relational queries and bloats simple lookups. See Context Graphs.
  • Always give the model a grounding instruction. A system prompt like “answer only from the provided context” prevents the model from inventing answers when retrieval is thin.
  • Format consistently. Whatever section delimiters you choose (=== CONTEXT ===, Chunk N, Source:), keep them stable across calls so the model learns the structure.
  • type: "all" is the simplest path when you need both knowledge and memories. One call, one result set, one build_string call.

6. Common mistakes


  • Query - request parameters and response shape
  • Memories - what POST /query with type: "memory" queries
  • Knowledge - what POST /query with type: "knowledge" queries
  • Context Graphs - what graph_context fields contain

If you are not using the SDK, use the helper below to call POST /query, format the response, and pass the result to your LLM.