Clone Taxonomy
Clone a taxonomy with optional modifications.
Purpose: Creates a NEW taxonomy (with new ID) based on an existing one. This is the recommended way to iterate on taxonomy designs when you need to modify core logic that PATCH doesn’t allow (config, retriever_id, input_mappings).
Clone vs PATCH vs Template:
- PATCH: Update metadata only (name, description, metadata)
- Clone: Copy and modify core logic (config, retriever, collections)
- Template: Start from a pre-configured pattern (for new projects)
Common Use Cases:
- Fix configuration errors without losing join history
- Change retriever or input mappings
- Modify enrichment fields or collection configuration
- Test modifications before replacing production taxonomy
- Create variants for different datasets
How it works:
- Source taxonomy is copied
- You provide a new name (REQUIRED)
- Optionally override any other fields (description, config)
- A new taxonomy is created with a new ID
- Original taxonomy remains unchanged
Authorizations
Mixpeek API key, sent as Authorization: Bearer mxp_sk_.... Create one in Studio under Settings → API Keys, or with an admin key via POST /v1/organizations/users/{user_email}/api-keys. A missing header returns 403; an invalid or revoked key returns 401.
Namespace id (ns_...), not the namespace name. This scopes the request rather than authenticating it, and it is required on every operation marked x-mixpeek-namespace-scoped.
Path Parameters
Source taxonomy ID or name to clone.
Body
Request to clone a taxonomy with optional modifications.
Purpose: Cloning creates a NEW taxonomy (with new ID) based on an existing one, allowing you to make changes that aren't allowed via PATCH (config, retriever_id, collections). This is the recommended way to iterate on taxonomy designs.
Clone vs Template vs Version:
- Clone: Copy THIS taxonomy and modify it (for iteration/fixes)
- Template: Create taxonomy from a reusable pattern (for new projects)
- Version: (Not implemented) - Use clone instead
Use Cases:
- Fix configuration errors without losing join history
- Change retriever or input mappings
- Change target collections
- Test modifications before replacing production taxonomy
- Create variants for different datasets
All fields are OPTIONAL:
- Omit a field to keep the original value
- Provide a field to override the original value
- taxonomy_name is REQUIRED (clones must have unique names)
REQUIRED. Name for the cloned taxonomy. Must be unique and different from the source taxonomy.
1"product_tags_v2"
"org_hierarchy_strict"
OPTIONAL. Description override. If omitted, copies from source taxonomy.
"Cloned from product_tags with updated retriever"
Configuration for a flat taxonomy - single source collection with one retriever.
- FlatTaxonomyConfig
- HierarchicalTaxonomyConfig

