Workflow automation model

The public workflow surface starts with storage access and ends with results delivery.

Connectors

Connectors define cloud storage access for GCS, S3, and Azure Blob Storage.

Public connector concerns include:

• provider-specific credentials
• connector scopes: import, export, or both
• import_mode
• optional export_base_path
• connection testing and source browsing

The connector itself does not import or export anything. It defines where those operations are allowed to run.

Import jobs

An import job uses a connector to create media items in an index.

Key public import controls:

• source prefix
• file pattern
• recursive scan behavior
• optional import mode override

Import jobs are asynchronous and expose progress, created media IDs, failed files, and skipped files.

Export jobs

An export job packages result data either for download or connector-based delivery.

Exports can target:

• an entire index
• one specific prompt run

They can optionally write to a destination connector rather than returning only a download URL.

Index automations

Automations are persistent per-index configurations for recurring workflow behavior.

Import automations

Import automations watch a connector location and trigger import processing with:

• source connector
• prefix and pattern filters
• debounce interval
• recursive behavior
• a prompt_preset that must include prompt_id

Export automations

Export automations send completed results to a destination connector with an optional destination subpath.

Webhooks

Webhooks push lifecycle events out of VideoVector.

Typical public webhook events include:

• media creation and processing events
• prompt run lifecycle events
• export completion and failure
• import job completion, failure, and progress

Webhook delivery is observable. The public surface includes delivery logs, retry controls, secret rotation, and event-name discovery.

Choosing the right delivery mechanism

Use connectors and jobs when:

• the destination is cloud storage
• the workflow wants file-oriented data movement

Use webhooks when:

• an external application needs real-time event notifications
• downstream logic is event-driven

Use automations when:

• the workflow should persist per index rather than requiring an operator to recreate each job

Failure boundaries

Each workflow resource has its own public failure surface:

• connector test failures
• import job failed and skipped file lists
• export job status and error fields
• webhook delivery attempt logs and manual retry

That separation is important. A successful import does not imply a successful export, and a successful prompt run does not imply a successful webhook delivery.