Migrating from Extractor Names

Mixpeek’s public vocabulary is modality + features: you configure collections by picking features (image_search, faces, onscreen_text, …), and the platform resolves the implementation internally. Built-in extractor names — image_extractor, universal_extractor, face_identity_extractor, and friends — are internal implementation details and no longer appear in new API payloads, errors, or docs. Nothing breaks. Existing configs and SDK clients that pass feature_extractor: {...} keep working: known built-in extractor names are accepted as deprecated aliases and resolved to their feature through the same catalog that powers the features path. Responses carry a deprecation notice pointing at features: [...].

This page is the one place old names are documented, for migration. Custom extractors you publish yourself are not deprecated — your plugin is your vocabulary, selected as custom:<plugin_name>.

Alias map

Deprecated extractor name	Use instead	Modality
`image_extractor`	`features: ["image_search"]`	image
`image_extractor` (PDF input)	`features: ["document_search"]`	document
`universal_extractor`	`features: ["video_search"]`	video
`text_extractor`	`features: ["text_search"]`	text
`audio_fingerprint_extractor`	`features: ["audio_search"]` (audio) or `features: ["audio_fingerprint"]` (in-video adder)	audio / video
`face_identity_extractor`	`features: ["faces"]`	image, video, document
`scrolling_text_extractor`	`features: ["onscreen_text"]`	video
`document_graph_extractor`	`features: ["document_layout"]`	document
`web_scraper`	`features: ["web_crawl"]`	web
`multimodal_extractor`	`features: ["multimodal_understanding"]`	any
`gemini_multifile_extractor`	`features: ["multimodal_understanding"]`	any
`passthrough_extractor`	`features: ["storage_only"]`	any

The live menu — including keys, display names, and rates — is always GET /v1/collections/features (discovery).

Before / after

Before (still works, deprecated):

{
  "collection_name": "press-footage",
  "source": { "type": "bucket", "bucket_ids": ["bkt_123"] },
  "feature_extractor": {
    "feature_extractor_name": "face_identity_extractor",
    "version": "v1",
    "input_mappings": { "video": "video_url" }
  }
}

After:

{
  "collection_name": "press-footage",
  "source": { "type": "bucket", "bucket_ids": ["bkt_123"] },
  "features": ["faces"]
}

The features path also defaults input_mappings for the standard uploads bucket properties (image, video, audio, pdf, content, url) — see default input wiring. If you need explicit input mappings, field passthrough, or extractor parameters, the feature_extractor config object remains the advanced path.

What you don’t need to migrate

Existing collections — they keep running unchanged. Aliases have no sunset date.
Feature URIs — query-side references like mixpeek://text_extractor@v1/... in existing retrievers remain valid contracts; they pin the pipeline version that produced your vectors.
Custom extractors — your own plugins keep their explicit names.

Why this changed

Pricing and configuration now share one vocabulary: features applied to modality units (images, video minutes, pages, tokens). When Mixpeek swaps or upgrades the models behind a feature, nothing about your config or your rates moves. See Billing & Pricing for how features are priced.

Get started

Connect your data

Extract features

Build retrievers

Enrich & organize

Integrate & operate

Resources

Migrating from Extractor Names

Alias map

Before / after

What you don’t need to migrate

Why this changed

​Alias map

​Before / after

​What you don’t need to migrate

​Why this changed

Alias map

Before / after

What you don’t need to migrate

Why this changed