Skip to main content
POST
Full recall for knowledge base

When to use it

/recall/full_recall is the primary endpoint for retrieving knowledge (documents, app sources). It runs a multi-stage pipeline that combines:
  1. Metadata filtering (deterministic scoping)
  2. Hybrid retrieval (semantic + keyword)
  3. Graph traversal (entity relationships)
  4. Personalized ranking (user, agent, task)
Use this for document-grounded queries: “What’s in our Q4 contract?”, “Find pricing decisions from the last sprint.” For user-specific memories (preferences, conversation history), use POST /recall/recall_preferences instead.

Endpoint

  • Auth: Bearer token
  • Idempotency: Read-only
  • Async: No

Example

Request parameters

Metadata filters

This field matches OpenAPI schema RecallSearchRequest.metadata_filters (see api-reference/openapi.json).
  • Optional object for exact-match metadata scoping; all conditions are ANDed.
  • Tenant-level: top-level keys (except the reserved nested object below) must match tenant metadata field names declared with enable_match in tenant_metadata_schema. Values use plain equality to stored tenant metadata. These are pre-filtered in the vector store, so they are fast.
  • Document-level: nest an object under the key additional_metadata (matches the ingestion field name). Keys and values use plain equality to the per-source data you sent as additional_metadata at ingestion. Applied post-retrieval — the engine over-fetches (~3x) to compensate. document_metadata is also accepted as a legacy alias for the nested key.
  • Not supported in this contract: range operators, regular-expression operators, or Mongo-style operators such as $gte, $lt, $in, or $regex.

Modes

In thinking mode, HydraDB runs multiple sub-queries against the index and reranks results before returning.

Response

graph_context populates only when:
  • You set graph_context: true in the request, and
  • Your ingested content has linked relationships in the graph.
If either condition is missing, the fields return as empty arrays. See Essentials → Context Graphs.

Behavior notes

thinking mode is the personalized path. The default fast mode uses a single retrieval pass. thinking mode adds query expansion, reranking, and forceful-relation context. For B2C apps where personalized recall matters, prefer thinking.
  • For user memories instead: Recall preferences – same parameters, targets the memory collection
  • For exact-match search: Boolean recall – full-text search with AND/OR/PHRASE operators

Errors

Common codes: 400 INVALID_PARAMETERS, 404 TENANT_NOT_FOUND, 422 VALIDATION_ERROR, 429 RATE_LIMITED. See Error Responses for the full list. Read more: Essentials → Recall · Essentials → Context Graphs

How to use API Results

Recall responses are chunks of data from knoledge, memory and graph relations in structured JSON. To extract context, we parse the data out of the response strucutre and feed it in prose to an LLM. For further details, explore Essentials → How to Use API Results.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Body

application/json

Request body for full recall (sources) and recall preferences (memories).

tenant_id
string
required

Unique identifier for the tenant/organization

Example:

"tenant_1234"

query
string
required

Search terms to find relevant content

Example:

"Which mode does user prefer"

sub_tenant_id
string | null

Optional sub-tenant identifier used to organize data within a tenant. If omitted, the default sub-tenant created during tenant setup will be used.

Example:

"sub_tenant_4567"

max_results
integer | null

Maximum number of results to return

mode
enum<string>
default:fast

Retrieval mode to use ('fast' or 'thinking')

Available options:
fast,
thinking
alpha
default:0.8

Search ranking algorithm parameter (0.0-1.0 or 'auto')

recency_bias
number
default:0

Preference for newer content (0.0 = no bias, 1.0 = strong recency preference)

Example:

1

graph_context
boolean
default:false

Enable graph context for search results

Example:

true

search_forceful_relations
boolean
default:true

Whether to search for forceful relations in thinking mode to augment context

Example:

true

additional_context
string | null

Additional context provided by the user to guide retrieval

metadata_filters
Metadata Filters · object | null

Optional object for exact-match metadata scoping. All provided conditions are combined with AND. Top-level keys (except the reserved nested object described below) must match tenant-level metadata field names declared with enable_match in tenant_metadata_schema; each value is compared with plain equality to the stored tenant metadata value for that field. For document-level metadata, supply a nested object under the key "additional_metadata" whose keys and values are compared with plain equality to per-source document metadata. Only equality on scalar-compatible values is part of this contract—do not send range operators, regular-expression operators, or Mongo-style operators such as $gte, $lt, $in, or $regex.

Example:

Response

Successful Response

Result of a hybrid search retrieval operation.

chunks
VectorStoreChunk · object[]
Example:
sources
SourceInfo · object[]

Deduplicated source documents corresponding to the returned chunks

graph_context
GraphContext · object

Graph context containing query-based paths and chunk-based relation paths.

additional_context
Additional Context · object

Map of chunk_uuid to VectorStoreChunk for extra context from forcefully related sources. Use chunk.extra_context_ids to look up chunks: extra_context[id] for id in chunk.extra_context_ids.