---
title: "Test taxonomy configuration (validation only) — DEPRECATED path"
method: POST
path: "/v1/taxonomies/execute/{taxonomy_identifier}"
tags: ["Taxonomies"]
deprecated: true
---

# Test taxonomy configuration (validation only) — DEPRECATED path

`POST /v1/taxonomies/execute/{taxonomy_identifier}`

> **Deprecated.**

⚠️ VALIDATION ENDPOINT ONLY - Not for production enrichment!

DEPRECATED path shape — prefer POST /taxonomies/{id}/execute (id-first,
consistent with retrievers). This verb-first path still works.

This endpoint validates taxonomy configuration with 1-5 sample documents.
Results are returned immediately and NOT persisted to any collection.

❌ DO NOT USE FOR:
- Enriching entire collections (use taxonomy_applications instead)
- Batch processing documents (automatic during ingestion)
- Persisting enriched documents (use retriever pipelines instead)

✅ USE THIS FOR:
- Testing taxonomy configuration is correct
- Validating retriever finds matching taxonomy nodes
- Checking enrichment fields are properly applied
- Development/debugging taxonomy setup

📚 FOR PRODUCTION ENRICHMENT:

Automatic (during ingestion):
  1. Create taxonomy: POST /taxonomies
  2. Attach to collection: PUT /collections/{id} with taxonomy_applications field
  3. Ingest documents: Documents are automatically enriched by engine

On-the-fly (during retrieval):
  1. Add taxonomy_join stage to retriever pipeline
  2. Execute retriever: GET /retrievers/{id}/execute
  3. Results include enriched documents (not persisted)

See API documentation for Collections and Retrievers for details.

## Path parameters

- `taxonomy_identifier` string, required — Taxonomy ID or name to validate

## Query parameters

- `version` integer, nullable — Optional taxonomy version (defaults to latest)

## Request body

- union
  - ExecuteTaxonomyRequest — Request model for on-demand taxonomy validation and testing ONLY. ⚠️ IMPORTANT: This endpoint is ONLY for testing taxonomy configuration with sample documents. DO NOT USE THIS FOR BATCH ENRICHMENT: ❌ Do NOT use this to enrich an entire collection ❌ Do NOT use source_collection_id expecting batch processing ❌ Do NOT use target_collection_id expecting persistence HOW TAXONOMY ENRICHMENT ACTUALLY WORKS: ✅ Automatic during ingestion: Attach taxonomies to collections via `taxonomy_applications` ✅ On-the-fly in retrieval: Add `taxonomy_join` stage to retriever pipelines This endpoint validates: - Taxonomy configuration is correct - Retriever can find matching taxonomy nodes - Enrichment fields are properly applied For production enrichment, see: - Collections API: attach taxonomies via `taxonomy_applications` field - Retrievers API: add `taxonomy_join` stage for on-the-fly enrichment
    - `taxonomy` TaxonomyModelInput, required — Primary Pydantic model representing a taxonomy definition.
      - `taxonomy_id` string — Unique identifier for the taxonomy
      - `version` integer — Monotonic version number of the taxonomy configuration
      - `taxonomy_name` string, required — A unique name for the taxonomy within the namespace.
      - `description` string, nullable — Optional human-readable description.
      - `retriever_id` string, nullable — Optional taxonomy-level retriever (prefer per-layer).
      - `input_mappings` InputMapping[], nullable — Optional taxonomy-level inputs (prefer per-layer).
        - `input_key` string, required — Key used in the constructed inputs payload.
        - `source_type` 'payload' | 'literal' | 'vector' | 'blob' — Where the value for an input should be retrieved from.
        - `path` string, nullable — Dot-notation path when source_type is PAYLOAD or VECTOR. PAYLOAD paths resolve from the document's ROOT fields — each document/source_document dict IS the payload (e.g. path 'text' reads {'text': ...}); a {'payload': {...}} envelope is also accepted as a fallback.
        - `override` unknown
      - `config` union, required — Configuration specific to the taxonomy type.
        - FlatTaxonomyConfigInput — Configuration for a *flat* taxonomy - single source collection with one retriever.
          - `taxonomy_type` 'flat' — Discriminator identifying this as a flat taxonomy.
          - `retriever_id` string, required — The retriever to use for matching against the source collection.
          - `input_mappings` InputMapping[], required — Input mappings defining how to construct retriever inputs.
            - `input_key` string, required — Key used in the constructed inputs payload.
            - `source_type` 'payload' | 'literal' | 'vector' | 'blob' — Where the value for an input should be retrieved from.
            - `path` string, nullable — Dot-notation path when source_type is PAYLOAD or VECTOR. PAYLOAD paths resolve from the document's ROOT fields — each document/source_document dict IS the payload (e.g. path 'text' reads {'text': ...}); a {'payload': {...}} envelope is also accepted as a fallback.
            - `override` unknown
          - `source_collection` SourceCollectionInput, required — A source collection for a flat taxonomy.
            - `collection_id` string, required — The ID of the source collection for the taxonomy.
            - `enrichment_fields` EnrichmentField[], nullable — Fields to copy from matched taxonomy node when enriching (append/replace semantics). If omitted, the full payload is copied.
              - …
          - `step_analytics` StepAnalyticsConfigInput — Configuration for step-by-step transition analytics on taxonomy assignments. Enables analysis of how documents progress through taxonomy labels as a temporal sequence, answering questions like: - How long from "inquiry" to "closed_won"? - What % of "inquiry" emails reach "proposal"? - Which sender domains correlate with faster progression? Use Cases: 1. Email Thread Analysis: - Track progression: inquiry → followup → proposal → closed_won - Identify which subject lines correlate with faster closure 2. Content Workflow Tracking: - Monitor: draft → review → approved → published - Find bottlenecks and optimization opportunities 3. Safety Compliance Monitoring: - Trace: violation_detected → investigated → resolved - Track resolution times and success rates Attributes: timestamp_field: Document field containing event timestamp sequence_id_field: Field that groups related documents into sequences step_key_source: How to extract the step identifier (label/node_id/custom field) step_key_field_path: Required if step_key_source='field_path' covariates: List of predictor variables to analyze for conversion lift max_sequence_duration_days: Filter out sequences longer than this (data quality) Example: ```python # Email thread analysis configuration StepAnalyticsConfig( timestamp_field="Date", # Email timestamp sequence_id_field="Thread-Index", # Groups emails in same thread step_key_source="assignment_label", # Use taxonomy label as step covariates=[ CovariateConfig( field_path="sender_domain", covariate_type="categorical", name="Sender Domain" ), CovariateConfig( field_path="word_count", covariate_type="numeric", name="Email Length" ) ], max_sequence_duration_days=90 # Ignore threads >90 days ) ```
            - `timestamp_field` string, required — Document field containing event timestamp (e.g., 'Date', 'created_at', 'metadata.timestamp')
            - `sequence_id_field` string, required — Document field that groups related items into a sequence (e.g., 'Thread-Index', 'session_id', 'user_id')
            - `step_key_source` 'assignment_label' | 'assignment_node_id' | 'field_path' — Defines how to extract the step key from documents for sequence analysis. The step key identifies which stage/state a document is in for transition analytics. Examples: ASSIGNMENT_LABEL: Use the taxonomy's assigned label (e.g., "inquiry", "proposal") ASSIGNMENT_NODE_ID: Use the taxonomy node ID (e.g., "node_sales_inquiry") FIELD_PATH: Use a custom document field (e.g., "metadata.workflow_stage")
            - `step_key_field_path` string, nullable — Required if step_key_source='field_path'. Dot-notation path to step value in document.
            - `covariates` CovariateConfig[] — Predictor fields to analyze for conversion lift (categorical, numeric, embedding, cluster)
              - …
            - `max_sequence_duration_days` integer, nullable — Maximum allowed duration for a sequence. Sequences beyond this are flagged as data quality issues.
        - HierarchicalTaxonomyConfigInput — Hybrid hierarchical taxonomy configuration supporting inference with manual additions. All hierarchical taxonomies are hybrid: - Base hierarchy can be inferred via schema, clustering, or LLM - Additional collections can be explicitly added with specific retrievers - Supports mixing inference strategies with manual additions/overrides Examples: 1. Pure inference: Set inference_strategy + inference_collections 2. Pure manual: Set hierarchical_nodes only 3. Hybrid: Set inference_strategy + inference_collections + hierarchical_nodes (infers base from collections, adds/overrides with explicit nodes)
          - `taxonomy_type` 'hierarchical' — Discriminator identifying this as a hierarchical taxonomy.
          - `retriever_id` string, nullable — Default retriever to use for all nodes unless overridden per-node.
          - `input_mappings` InputMapping[], nullable — Default input mappings for all nodes unless overridden per-node.
            - `input_key` string, required — Key used in the constructed inputs payload.
            - `source_type` 'payload' | 'literal' | 'vector' | 'blob' — Where the value for an input should be retrieved from.
            - `path` string, nullable — Dot-notation path when source_type is PAYLOAD or VECTOR. PAYLOAD paths resolve from the document's ROOT fields — each document/source_document dict IS the payload (e.g. path 'text' reads {'text': ...}); a {'payload': {...}} envelope is also accepted as a fallback.
            - `override` unknown
          - `inference_strategy` 'schema' | 'cluster' | 'llm' — Strategy for inferring the base hierarchy structure. Can be combined with manual overrides via hierarchical_nodes for hybrid configuration: - SCHEMA: Infer based on overlapping collection schemas - CLUSTER: Infer based on clustering algorithms and overlap detection - LLM: Infer using AI/language models
          - `inference_collections` string[], nullable — Collection IDs to use for hierarchy inference. The inference_strategy will analyze these collections to discover relationships. Can be combined with hierarchical_nodes for hybrid configuration.
          - `llm_provider` 'openai_chat_v1', nullable — LLM provider to use for hierarchy inference (default openai_chat_v1)
          - `llm_model` string, nullable — LLM model name (e.g., gpt-4o-mini)
          - `llm_prompt_template` string, nullable — Optional prompt template. Variables available: {collection_id}, {collection_name}.
          - `llm_sample_size` integer — Optional number of sample docs to include in prompts (0 = disabled).
          - `cluster_ids` string[], nullable — Cluster IDs to use for CLUSTER inference strategy
          - `cluster_overlap_threshold` number — Minimum overlap ratio to establish parent-child relationship between clusters
          - `hierarchical_nodes` HierarchicalNodeInput[], nullable — Explicit node definitions that either: 1) Define the entire hierarchy (when inference_strategy is None), 2) Add additional nodes to an inferred hierarchy, or 3) Override specific relationships in an inferred hierarchy. Supports true hybrid: infer from some collections, manually add others.
            - `collection_id` string, required — REQUIRED. Collection ID representing this node in the hierarchy. Must reference an existing collection containing documents for this hierarchy level. Format: 'col_' prefix followed by alphanumeric/underscore characters. Used to: Match documents against this level, identify node in path, store enrichment data. Example: 'col_executives' for executive level, 'col_products_phones' for phones category.
            - `parent_collection_id` string, nullable — OPTIONAL. Collection ID of the parent node in the hierarchy. When None: This is a root node (top of hierarchy). When set: References parent node's collection_id, creating parent-child relationship. Format: Same as collection_id ('col_' prefix). Used to: Build hierarchy tree, determine inheritance order, construct path arrays. Example: 'col_managers' is parent of 'col_executives', 'col_products' is parent of 'col_electronics'. Validation: Must reference a valid collection_id from another node in same taxonomy.
            - `label` string, nullable — OPTIONAL. Human-readable display name for this hierarchy node. Used in UI, visualizations, and taxonomy assignment results. NOT REQUIRED - When None: collection name or auto-generated label may be used. Format: Free text, typically title case, 2-50 characters. Examples: 'Executive Leadership', 'Mobile Phones', 'Engineering Team'. Can be LLM-generated or manually specified during taxonomy creation.
            - `summary` string, nullable — OPTIONAL. Brief description of this hierarchy level and its contents. Used for: Documentation, UI tooltips, understanding hierarchy structure. NOT REQUIRED - When None: no summary available for this node. Format: Free text, typically 1-3 sentences, up to 500 characters. Can be LLM-generated or manually provided.
            - `keywords` string[], nullable — OPTIONAL. Keywords or tags describing this hierarchy level. Used for: Search, filtering, categorization, LLM understanding. NOT REQUIRED - When None: no keywords defined for this node. Format: List of strings, typically 3-10 keywords per node. Can be LLM-generated from collection contents or manually specified.
            - `retriever_id` string, nullable — OPTIONAL. Retriever to use for matching documents at this hierarchy level. When None: Uses taxonomy-level retriever_id (inheritance from parent config). When set: Overrides taxonomy-level retriever for this specific node. Format: 'ret_' prefix followed by alphanumeric characters. Use for: Specialized matching at certain levels (e.g., face recognition for employees, semantic search for products). Must reference an existing RetrieverModel.
            - `enrichment_fields` EnrichmentField[], nullable — OPTIONAL. Fields to enrich into documents when they match this hierarchy level. Specifies which properties from node collection to copy to matched documents. When None: No field-level enrichment (only taxonomy assignment recorded). Format: List of EnrichmentField objects with field_path and merge_mode. Inheritance: Child nodes inherit all parent enrichment_fields plus their own. Example: executives node adds 'executive_level' on top of inherited 'employee_id', 'department'.
              - …
            - `input_mappings` InputMapping[], nullable — OPTIONAL. Custom input mappings for the retriever at this hierarchy level. Specifies how to construct retriever inputs from document features. When None: Uses taxonomy-level input_mappings (inheritance). When set: Overrides taxonomy-level mappings for this specific node. Format: List of InputMapping objects specifying input_key, source_type, path. Use for: Different matching strategies at different levels (e.g., face at employee level, text at department level).
              - …
          - `step_analytics` StepAnalyticsConfigInput — Configuration for step-by-step transition analytics on taxonomy assignments. Enables analysis of how documents progress through taxonomy labels as a temporal sequence, answering questions like: - How long from "inquiry" to "closed_won"? - What % of "inquiry" emails reach "proposal"? - Which sender domains correlate with faster progression? Use Cases: 1. Email Thread Analysis: - Track progression: inquiry → followup → proposal → closed_won - Identify which subject lines correlate with faster closure 2. Content Workflow Tracking: - Monitor: draft → review → approved → published - Find bottlenecks and optimization opportunities 3. Safety Compliance Monitoring: - Trace: violation_detected → investigated → resolved - Track resolution times and success rates Attributes: timestamp_field: Document field containing event timestamp sequence_id_field: Field that groups related documents into sequences step_key_source: How to extract the step identifier (label/node_id/custom field) step_key_field_path: Required if step_key_source='field_path' covariates: List of predictor variables to analyze for conversion lift max_sequence_duration_days: Filter out sequences longer than this (data quality) Example: ```python # Email thread analysis configuration StepAnalyticsConfig( timestamp_field="Date", # Email timestamp sequence_id_field="Thread-Index", # Groups emails in same thread step_key_source="assignment_label", # Use taxonomy label as step covariates=[ CovariateConfig( field_path="sender_domain", covariate_type="categorical", name="Sender Domain" ), CovariateConfig( field_path="word_count", covariate_type="numeric", name="Email Length" ) ], max_sequence_duration_days=90 # Ignore threads >90 days ) ```
            - `timestamp_field` string, required — Document field containing event timestamp (e.g., 'Date', 'created_at', 'metadata.timestamp')
            - `sequence_id_field` string, required — Document field that groups related items into a sequence (e.g., 'Thread-Index', 'session_id', 'user_id')
            - `step_key_source` 'assignment_label' | 'assignment_node_id' | 'field_path' — Defines how to extract the step key from documents for sequence analysis. The step key identifies which stage/state a document is in for transition analytics. Examples: ASSIGNMENT_LABEL: Use the taxonomy's assigned label (e.g., "inquiry", "proposal") ASSIGNMENT_NODE_ID: Use the taxonomy node ID (e.g., "node_sales_inquiry") FIELD_PATH: Use a custom document field (e.g., "metadata.workflow_stage")
            - `step_key_field_path` string, nullable — Required if step_key_source='field_path'. Dot-notation path to step value in document.
            - `covariates` CovariateConfig[] — Predictor fields to analyze for conversion lift (categorical, numeric, embedding, cluster)
              - …
            - `max_sequence_duration_days` integer, nullable — Maximum allowed duration for a sequence. Sequences beyond this are flagged as data quality issues.
      - `ready` boolean — Whether the taxonomy is ready for use. False for async inference (cluster/LLM) that needs processing. True for flat/explicit hierarchies.
      - `created_at` string, date-time — Creation timestamp for this taxonomy record
      - `metadata` object — Additional user-defined metadata for the taxonomy
    - `retriever` RetrieverModelInput — Retriever model.
      - `retriever_id` string — Unique identifier for the retriever
      - `retriever_name` string, required — Name of the retriever
      - `description` string, nullable — Description of the retriever
      - `visibility` 'private' | 'public' | 'marketplace' — Visibility level of a retriever determining who can access it.
      - `marketplace_listing_id` string, nullable — Associated marketplace listing ID when visibility is MARKETPLACE
      - `requires_subscription` boolean — Whether this retriever requires an active subscription to access (marketplace only)
      - `input_schema` RetrieverSchema, required — Schema definition for retriever inputs.
        - `properties` object — Schema properties for retriever inputs
      - `collection_ids` string[], required — List of collection IDs
      - `stages` StageInstanceConfig[], required — List of stage configurations
        - `stage_name` string, required
        - `stage_id` string, nullable — Stage implementation ID (overrides stage_name for lookups)
        - `parameters` object — Stage parameters
        - `pre_filters` LogicalOperatorInput — Represents a logical operation (AND, OR, NOT) on filter conditions. Allows nesting with a defined depth limit. Also supports shorthand syntax where field names can be passed directly as key-value pairs for equality filtering (e.g., {"metadata.title": "value"}).
          - `AND` union[], nullable — Logical AND operation - all conditions must be true
            - union
              - …
          - `OR` union[], nullable — Logical OR operation - at least one condition must be true
            - union
              - …
          - `NOT` union[], nullable — Logical NOT operation - all conditions must be false
            - union
              - …
          - `case_sensitive` boolean, nullable — Whether to perform case-sensitive matching
        - `post_filters` LogicalOperatorInput — Represents a logical operation (AND, OR, NOT) on filter conditions. Allows nesting with a defined depth limit. Also supports shorthand syntax where field names can be passed directly as key-value pairs for equality filtering (e.g., {"metadata.title": "value"}).
          - `AND` union[], nullable — Logical AND operation - all conditions must be true
            - union
              - …
          - `OR` union[], nullable — Logical OR operation - at least one condition must be true
            - union
              - …
          - `NOT` union[], nullable — Logical NOT operation - all conditions must be false
            - union
              - …
          - `case_sensitive` boolean, nullable — Whether to perform case-sensitive matching
        - `stats` StagePerformanceInput — Performance statistics for a retriever stage.
          - `avg_execution_ms` number — Average execution time in milliseconds
          - `execution_count` integer — Number of times executed
          - `error_count` integer — Number of errors encountered
          - `last_executed_at` string, date-time, nullable — Last time this stage was executed
      - `cache_config` CacheConfig — Configuration for retriever result caching. Controls how retriever results are cached to improve performance and reduce redundant compute. Caching can be configured at specific stages in the retriever pipeline. If no stages are specified, the final results are cached by default.
        - `enabled` boolean — Whether caching is enabled for this retriever
        - `ttl_seconds` integer — Time-to-live for cached results in seconds. Default: 1 hour
        - `cache_stage_names` string[], nullable — List of stage names to cache results after. Stage names must match the stage_name field in the retriever's stages. If not specified, caches the final results after all stages. Examples: ['semantic_search'], ['semantic_search', 'rerank']
        - `exclude_fields` string[], nullable — Fields to exclude from caching (e.g., PII fields)
        - `stats` CacheStatistics — Statistics about cache performance.
          - `hit_count` integer — Number of cache hits
          - `miss_count` integer — Number of cache misses
          - `hit_rate` number — Cache hit rate (0.0 - 1.0)
          - `size_bytes` integer — Total size of cached data in bytes
          - `entry_count` integer — Number of entries in cache
          - `last_invalidated_at` string, date-time, nullable — When the cache was last invalidated
      - `created_at` string, date-time — When the retriever was created
      - `updated_at` string, date-time — When the retriever was last modified
      - `last_executed_at` string, date-time, nullable — When the retriever was last executed
      - `enabled` boolean — Whether the retriever is enabled (can be toggled on/off)
      - `status` 'active' | 'draft' | 'disabled' | 'error' — Status of a retriever.
      - `usage_stats` UsageStatistics — Usage statistics for a retriever.
        - `total_queries` integer — Total number of queries executed
        - `queries_last_24h` integer — Number of queries in the last 24 hours
        - `avg_latency_ms` number — Average latency in milliseconds
        - `error_rate` number — Error rate as a fraction (0.0 - 1.0)
        - `last_error` string, nullable — Most recent error message for debugging
        - `cache_hit_rate` number, nullable — Cache hit rate if caching is enabled (0.0 - 1.0)
      - `collections` CollectionDetail[], nullable — Expanded collection details with names and metadata
        - `collection_id` string, required — Collection identifier
        - `collection_name` string, required — Human-readable collection name
        - `document_count` integer, nullable — Number of documents in the collection
        - `enabled` boolean, nullable — Whether the collection is active
        - `last_indexed_at` string, date-time, nullable — When the collection was last indexed
      - `metadata` object — Custom key-value metadata
      - `tags` string[] — Tags for organization and filtering
      - `created_by` CreatorInfo — Information about who created or updated a resource.
        - `user_id` string, required — User identifier
        - `email` string, nullable — User email address
        - `name` string, nullable — User display name
      - `updated_by` CreatorInfo — Information about who created or updated a resource.
        - `user_id` string, required — User identifier
        - `email` string, nullable — User email address
        - `name` string, nullable — User display name
      - `version` integer — Version number (increments on each update)
      - `revision_history` RevisionHistoryEntry[] — History of changes (optional, last N changes)
        - `version` integer, required — Version number
        - `updated_at` string, date-time, required — When this version was created
        - `updated_by` string, nullable — User who made the change
        - `changes` string, nullable — Description of changes made
      - `health` HealthCheck — Health check information for a retriever.
        - `status` 'healthy' | 'degraded' | 'unhealthy' — Health status of a retriever.
        - `last_check` string, date-time, nullable — When the health was last checked
        - `issues` string[] — List of current issues if any
    - `source_documents` object[], nullable — Sample documents to test enrichment (typically 1-5 docs). Results are returned immediately, not persisted. ⚠️ Do NOT pass collection_id expecting batch processing!
    - `source_collection_id` string, nullable — ⚠️ IGNORED IN ON_DEMAND MODE. This field exists for legacy compatibility only. To enrich collections, use taxonomy_applications on the collection.
    - `target_collection_id` string, nullable — ⚠️ IGNORED IN ON_DEMAND MODE. This field exists for legacy compatibility only. Results are never persisted via this endpoint.
    - `join_mode` 'on_demand' | 'batch'
    - `batch_size` integer — Batch size for the scroll iterator
    - `scroll_filters` LogicalOperatorInput — Represents a logical operation (AND, OR, NOT) on filter conditions. Allows nesting with a defined depth limit. Also supports shorthand syntax where field names can be passed directly as key-value pairs for equality filtering (e.g., {"metadata.title": "value"}).
      - `AND` union[], nullable — Logical AND operation - all conditions must be true
        - union
          - LogicalOperatorInput — recursive
          - FilterCondition — Represents a single filter condition. Attributes: field: The field to filter on operator: The comparison operator value: The value to compare against
            - `field` string, required — Field name to filter on
            - `operator` 'eq' | 'ne' | 'gt' | 'lt' | 'gte' | 'lte' | 'in' | 'nin' | 'contains' | 'starts_with' | 'ends_with' | 'regex' | 'exists' | 'is_null' | 'text' | 'phrase' | 'geo_radius' | 'geo_bounding_box' | 'geo_polygon' — Supported filter operators across database implementations.
            - `value` union, required — Value to compare against
              - …
      - `OR` union[], nullable — Logical OR operation - at least one condition must be true
        - union
          - LogicalOperatorInput — recursive
          - FilterCondition — Represents a single filter condition. Attributes: field: The field to filter on operator: The comparison operator value: The value to compare against
            - `field` string, required — Field name to filter on
            - `operator` 'eq' | 'ne' | 'gt' | 'lt' | 'gte' | 'lte' | 'in' | 'nin' | 'contains' | 'starts_with' | 'ends_with' | 'regex' | 'exists' | 'is_null' | 'text' | 'phrase' | 'geo_radius' | 'geo_bounding_box' | 'geo_polygon' — Supported filter operators across database implementations.
            - `value` union, required — Value to compare against
              - …
      - `NOT` union[], nullable — Logical NOT operation - all conditions must be false
        - union
          - LogicalOperatorInput — recursive
          - FilterCondition — Represents a single filter condition. Attributes: field: The field to filter on operator: The comparison operator value: The value to compare against
            - `field` string, required — Field name to filter on
            - `operator` 'eq' | 'ne' | 'gt' | 'lt' | 'gte' | 'lte' | 'in' | 'nin' | 'contains' | 'starts_with' | 'ends_with' | 'regex' | 'exists' | 'is_null' | 'text' | 'phrase' | 'geo_radius' | 'geo_bounding_box' | 'geo_polygon' — Supported filter operators across database implementations.
            - `value` union, required — Value to compare against
              - …
      - `case_sensitive` boolean, nullable — Whether to perform case-sensitive matching
  - object

## Response `200`

Successful Response

- JoinResponse
  - `stats` JoinStats, required
    - `processed_docs` integer
    - `batches` integer
    - `errors` integer
    - `enriched` integer
  - `results` object[], nullable
  - `matches` TaxonomyMatch[], nullable — Flattened per-document match summaries extracted from processing_history — convenience for clients so they don't have to spelunk metadata.processing_history.
    - `document_id` string, nullable
    - `taxonomy_id` string, nullable
    - `taxonomy_name` string, nullable
    - `node_id` string, nullable
    - `label` string, nullable
    - `score` number, nullable
    - `path` string[], nullable
    - `hierarchy_level` integer, nullable
    - `enriched_fields` string[], nullable

## Other responses

- `400` — Bad Request
- `401` — Unauthorized
- `403` — Forbidden
- `404` — Not Found
- `422` — Validation Error
- `500` — Internal Server Error

---

[API](https://skmtc.net/mixpeek/apis/mixpeek-api.md) · [All operations](https://skmtc.net/mixpeek/apis/mixpeek-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/mixpeek/mixpeek-api/revisions/23e05292e326/schema)
