Skip to main content

Overview

Iconik is a cloud-native media asset management platform. By connecting Iconik to Mixpeek, you can automatically sync your media library — enabling search, classification, and analysis across video, image, and audio assets. Iconik uses the same connection sync pattern as all other Mixpeek storage integrations. Mixpeek polls Iconik for assets, downloads proxy files, and creates bucket objects with full metadata. It can also parse editorial project files into footage ↔ ad relationships (see Project-file linkage). Optionally, you can configure webhooks for real-time delete and update events.

Prerequisites

  • An Iconik account with assets
  • An Iconik App ID and Auth Token with read access to assets, proxies, and files
  • A Mixpeek account with an active namespace

Configuration

Connection-level fields

Sync-level fields

Setup

1

Create Iconik API credentials

  1. In the Iconik admin panel, go to Admin > Integrations > Applications
  2. Click Create Application
  3. Copy the App ID and Auth Token — you’ll need both for the Mixpeek connection
Use a dedicated application for the Mixpeek integration rather than a personal token. Application tokens don’t expire when a user leaves the organization.
2

Create the connection in Mixpeek

In the Mixpeek Studio, go to Settings > Storage Connections > Add Connection and select Iconik.Or via the API:
Save the returned connection_id.
3

Create a bucket with Iconik sync

Create a bucket and configure it to sync from your Iconik connection:
4

Verify ingestion

Monitor the sync status in Studio or via the API. Assets will be automatically downloaded (proxy files) and processed through your collection’s feature extractors.

Collection traversal and directory mapping

When you specify collection_ids in provider_filters, the connector recursively traverses the Iconik collection hierarchy (up to 10 levels deep) and maps the collection tree to a directory_path on each synced object. For example, an Iconik collection structure like:
produces objects with directory_path values like:
  • Brand Campaign/01 Product Shots/08 Outros
  • Brand Campaign/02 UGC Footage/01 Talent (Before)/01 Mature
  • Brand Campaign/03 High-End Footage
This path is available in source_metadata.directory_path and can be used for filtering in retrievers.

Glob filtering with path_patterns

Use path_patterns in provider_filters to include only assets whose directory_path matches one or more glob patterns. Patterns use standard fnmatch syntax and are case-insensitive.

Iconik metadata on objects and retriever results

When the connector syncs an Iconik asset into a bucket, it captures metadata from two sources and exposes them as source_metadata on the resulting bucket object.

Asset-level fields

These come from the Iconik asset record directly:

Custom metadata from views

The connector automatically discovers all metadata views configured in your Iconik workspace and fetches custom metadata for each asset across all views. Fields are flattened from Iconik’s nested field_values format into simple key-value pairs. Example fields (depending on your Iconik configuration): All populated custom metadata fields are included automatically — no configuration needed. If you want to limit metadata to a specific view, set metadata_view_id in the connection’s provider_config:

Project-file linkage

Beyond per-asset metadata, the Iconik connector captures the relationships between assets that come from editorial (NLE) projects. For Iconik NLE_PROJECT assets (e.g. an Adobe Premiere project — one per produced ad), the connector reads Iconik’s relations — the media assets the project uses, already parsed by Iconik — and attaches typed, directed edges to the object — Mixpeek’s first-class model for customer-owned relationships between objects. When the project file itself is downloadable (native .prproj, .fcpxml, or an xmeml .xml export), the connector additionally parses it to enrich each edge with clip order and timeline ticks — matched to the relations by footage file name. This is how an assembled ad is linked to every piece of footage it uses, with its position in the cut — captured as a saved value on the object at ingestion, not recomputed at query time.

What gets captured

For an NLE project asset, the connector emits one edge per related media asset, stored at the root of the object under edges: The connector also sets two root-level signals on the ad object: Plain media assets (raw footage) get no edges and pay no extra API calls — linkage capture is gated to NLE project assets. Everything is fully fail-open: a relations error or a missing/malformed project file never blocks asset ingestion (edges without a parseable project file simply carry no tick attributes).
Edges and these signals are customer-owned data and live at the object root, never under _internal. They flow automatically from the object through your collections into the document’s search payload, so they are available to retrievers.

Traversing the relationships

Once footage↔ad edges are on your documents, the traverse_edge retriever stage follows them at query time — e.g. starting from an ad, fetch every piece of footage it uses, carrying the clip order and start-ticks of each:
This linkage is a generalizable capability of Mixpeek’s source-adapter framework — any connector whose source carries a companion/sidecar file (an NLE project, an XMP sidecar, a per-object .json) can populate edges the same way. The Adobe Premiere xmeml parser is the Iconik-specific piece.

File resolution

The Iconik connector resolves downloadable files in priority order:
  1. Proxy URL — pre-signed download URL from GET /files/v1/assets/{id}/proxies/
  2. Original file URL — download URL from GET /files/v1/assets/{id}/formats/
Per asset, the connector makes: one asset metadata call, one proxy URL resolution call, and one metadata view call per discovered view (views are cached after the first asset).

Webhooks: delete and update

Mixpeek handles Iconik webhook events to keep your index in sync in real time, without waiting for the next poll cycle.

How it works

  1. Iconik POSTs events to a Mixpeek endpoint that includes your connection_id.
  2. Mixpeek verifies the X-Iconik-Signature header against the webhook_secret stored on that connection.
  3. assets.asset_deleted — Mixpeek finds every object synced from that Iconik asset and deletes them, cascading through OBJECT_DELETED to remove derived documents from your collections.
  4. assets.asset_updated — Mixpeek re-evaluates the asset against each sync config’s metadata_filters. If the asset no longer matches and reconcile_on_sync is enabled, the corresponding objects are unindexed.
  5. assets.asset_created — Acknowledged; the asset will be picked up on the next sync poll.

Setup

1

Add a webhook secret to the connection

Pick any high-entropy string (32+ chars) and store it as webhook_secret in the Iconik connection’s credentials. You can set it at create time or patch an existing connection.
cURL
2

Register the webhook in Iconik

In the Iconik admin panel:
  1. Go to Admin > Integrations > Webhooks
  2. Click Create Webhook
  3. Set the URL to https://api.mixpeek.com/v1/webhooks/iconik/{connection_id} — replace {connection_id} with the Mixpeek connection ID
  4. Subscribe to events: Asset Created, Asset Updated, Asset Deleted
  5. Save the webhook
3

Verify with a test delete

Delete a synced asset in Iconik and confirm the corresponding object disappears from your bucket. The webhook returns a JSON body documenting what it did:

Signature format

Mixpeek verifies inbound Iconik webhooks using HMAC-SHA256:
  • Header: X-Iconik-Signature: <hex_hmac_sha256>
  • HMAC computed as HMAC_SHA256(webhook_secret, raw_body) over the exact raw bytes of the request body.
  • Signatures are compared with hmac.compare_digest to avoid timing attacks.

Response codes

Modification detection

When skip_duplicates is true (default), re-syncing the same Iconik account skips assets whose date_modified hasn’t changed since the last sync. This makes continuous syncing efficient — only new or modified assets are re-processed. When skip_duplicates is false, every asset is re-downloaded and re-processed on each sync cycle, replacing existing objects with fresh ones.

Reconciliation

When reconcile_on_sync is enabled, each sync cycle checks whether previously synced assets still exist in Iconik. Assets that have been deleted from Iconik are automatically removed from your bucket.
Reconciliation checks each indexed object against the Iconik API on every sync cycle. For large libraries (10k+ assets), this adds API calls proportional to the number of indexed objects. Use it when stale objects are unacceptable.

Provider filters

Filter which Iconik assets get synced using provider_filters:

Sync modes

Troubleshooting

Verify your App ID and Auth Token are correct. The App ID is a UUID (e.g., e0f0ec84-4d63-...). Tokens can be regenerated in the Iconik admin panel under Admin > Integrations > Applications.
Only assets with proxy files or original files available are synced. Check that your Iconik credentials have read access to the files API (GET /files/v1/assets/{id}/proxies/).
Ensure skip_duplicates is set to true on your sync config. This deduplicates assets by their Iconik asset ID and modification timestamp.
Enable reconcile_on_sync on your sync config, or configure webhooks to handle assets.asset_deleted events for real-time cleanup.
The X-Iconik-Signature header doesn’t match. Verify the webhook_secret on your Mixpeek connection matches what Iconik is using to sign payloads.