v5
latestOpenAPI 3.1.02026-08-025631,1012.8 MBUpdate Sync Configuration
Update a sync configuration.
Path parameters
Request body
Optional human-readable description of the sync configuration. NOT REQUIRED. Used for documentation and UI display. Maximum 500 characters.
Optional custom metadata to replace existing metadata. NOT REQUIRED. Completely replaces existing metadata (not merged). Use for tagging, categorization, or custom attributes. Maximum 50 keys, values must be JSON-serializable.
Enumeration of task statuses for tracking asynchronous operations.
Task statuses indicate the current state of asynchronous operations like batch processing, object ingestion, clustering, and taxonomy execution.
Status Categories: Operation Statuses: Track progress of async operations Lifecycle Statuses: Track entity state (buckets, collections, namespaces)
Values: PENDING: Task is queued but has not started processing yet IN_PROGRESS: Task is currently being executed PROCESSING: Task is actively processing data (similar to IN_PROGRESS) COMPLETED: Task finished successfully with no errors COMPLETED_WITH_ERRORS: Task finished but some items failed (partial success) FAILED: Task encountered an error and could not complete CANCELED: Task was manually canceled by a user or system UNKNOWN: Task status could not be determined SKIPPED: Task was intentionally skipped DRAFT: Task is in draft state and not yet submitted
ACTIVE: Entity is active and operational (for buckets, collections, etc.)
ARCHIVED: Entity has been archived
SUSPENDED: Entity has been temporarily suspended
Terminal Statuses: COMPLETED, COMPLETED_WITH_ERRORS, FAILED, CANCELED are terminal statuses. Once a task reaches these states, it will not transition to another state.
Partial Success Handling: COMPLETED_WITH_ERRORS indicates that the operation completed but some documents/items failed. The task result includes: - List of successful items - List of failed items with error details - Success rate percentage This allows clients to handle partial success scenarios appropriately.
Polling Guidance: - Poll tasks in PENDING, QUEUED, IN_PROGRESS, or PROCESSING states - Stop polling when task reaches COMPLETED, COMPLETED_WITH_ERRORS, FAILED, or CANCELED - Use exponential backoff (1s → 30s) when polling
Optional flag to enable or disable the sync configuration. NOT REQUIRED. When False, sync will not process new files. Prefer using the /pause and /resume endpoints for clarity. Changes take effect immediately.
Optional new polling interval in seconds. NOT REQUIRED. Must be between 30 and 86400 seconds if provided. Only applies to 'continuous' and 'scheduled' sync modes. Lower values increase responsiveness but API usage.
Optional new batch size for file processing. NOT REQUIRED. Must be between 1 and 100 if provided. Larger batches improve throughput but use more memory. Changes apply to subsequent batches only.
If True, sync objects to the bucket without creating or submitting batches for collection processing. Objects are created in the bucket but no tier processing is triggered. NOT REQUIRED. When omitted, existing value is preserved.
Hard cap on objects processed per sync run. NOT REQUIRED. When omitted, existing value is preserved. Use to limit runaway syncs or control ingestion volume.
Provider-specific pre-filters pushed down to the storage API call. NOT REQUIRED. Completely replaces existing provider_filters (not merged). Each provider defines its own filter schema. Examples: - Iconik: {'collection_ids': [...], 'media_type': 'video,image', 'path_patterns': ['/Footage/']} - Google Drive: {'shared_drive_id': '0AH-Xabc123'} - S3: {'prefix': 'videos/'}
Example request
{
"description": "Pause sync temporarily",
"is_active": false
}Response
Successful Response
Unique identifier for the sync configuration.
Target bucket identifier (e.g. 'bkt_marketing_assets').
Storage connection identifier (e.g. 'conn_abc123').
Organization internal identifier (multi-tenancy scope).
Namespace identifier owning the bucket.
Source path in the external storage provider. Format varies by provider: s3/tigris='bucket/prefix', google_drive='folder_id', sharepoint='/sites/Name/Documents', snowflake='DB.SCHEMA.TABLE'.
Supported sync modes for external storage ingestion.
Polling interval in seconds (continuous mode). Up to 86400 (1 day) — slow intervals are a legitimate ops throttle (e.g. deliberately deprioritizing freshness lanes during a backfill), and the read model must accept any value the platform itself may have stored.
Number of files processed per sync batch.
Whether objects should be created immediately after confirmation.
Skip files whose hashes already exist in the bucket.
Sync-only mode: download and store files in the bucket without running them through the collection processing pipeline. Set to True during initial bulk ingestion, then flip to False to trigger processing once all files are synced.
Enumeration of task statuses for tracking asynchronous operations.
Task statuses indicate the current state of asynchronous operations like batch processing, object ingestion, clustering, and taxonomy execution.
Status Categories: Operation Statuses: Track progress of async operations Lifecycle Statuses: Track entity state (buckets, collections, namespaces)
Values: PENDING: Task is queued but has not started processing yet IN_PROGRESS: Task is currently being executed PROCESSING: Task is actively processing data (similar to IN_PROGRESS) COMPLETED: Task finished successfully with no errors COMPLETED_WITH_ERRORS: Task finished but some items failed (partial success) FAILED: Task encountered an error and could not complete CANCELED: Task was manually canceled by a user or system UNKNOWN: Task status could not be determined SKIPPED: Task was intentionally skipped DRAFT: Task is in draft state and not yet submitted
ACTIVE: Entity is active and operational (for buckets, collections, etc.)
ARCHIVED: Entity has been archived
SUSPENDED: Entity has been temporarily suspended
Terminal Statuses: COMPLETED, COMPLETED_WITH_ERRORS, FAILED, CANCELED are terminal statuses. Once a task reaches these states, it will not transition to another state.
Partial Success Handling: COMPLETED_WITH_ERRORS indicates that the operation completed but some documents/items failed. The task result includes: - List of successful items - List of failed items with error details - Success rate percentage This allows clients to handle partial success scenarios appropriately.
Polling Guidance: - Poll tasks in PENDING, QUEUED, IN_PROGRESS, or PROCESSING states - Stop polling when task reaches COMPLETED, COMPLETED_WITH_ERRORS, FAILED, or CANCELED - Use exponential backoff (1s → 30s) when polling
Convenience flag used for filtering active syncs.
Cumulative count of files found in source across all runs.
Cumulative count of successfully synced files.
Cumulative count of failed files (sent to DLQ after 3 retries).
Cumulative bytes transferred across all runs.
When sync configuration was created.
Last modification timestamp.
When last successful sync completed. Used for incremental syncs.
Per-shard last-sync timestamps keyed by shard value (e.g. collection_id). When a new shard is added, its absence here forces a full scan even if the global last_sync_at is set.
Scheduled time for next sync (continuous/scheduled modes).
User identifier that created the sync configuration.
Most recent error message if sync attempts failed.
Provider-specific pre-filters pushed down to the API call. The sync engine passes these to iter_objects() without interpretation. Each provider defines its own schema. Applied BEFORE file_filters. Examples: Iconik {'collection_ids': [...]}, Google Drive {'shared_drive_id': '...'}
Storage provider type for API progress views (for example: s3, google_drive, iconik).
Arbitrary metadata supplied by the user.
Worker ID that currently holds the lock for this sync
Timestamp when lock was acquired
Timestamp when lock expires (for stale lock recovery)
A full sweep was requested (trigger?full_sync=true) while a run held the lock. The finishing run dispatches it automatically on lock release.
Whether sync is currently paused (user-controlled)
Reason for pause
Timestamp when paused
User who paused the sync
Hard cap on objects per sync run (prevents runaway syncs)
Maximum objects per batch chunk
Number of objects per batch chunk (for concurrent processing)
UUID for current/last sync run
Increments on each sync execution
List of batch IDs created by this sync
List of task IDs for batches
Total number of batches created
Whether resuming partial runs is enabled
Last page/cursor processed (for paginated APIs like Google Drive)
Last primary key processed (for database syncs with stable ordering)
Count of objects processed in current/last run
How often to checkpoint (in objects). Default: every 1000 objects
Convenience mirror of the current resume cursor for API progress views.
Per-(config, shard) high-water checkpoints keyed by shard key (e.g. collection_id for parallel fan-outs, 'pages_N_M' for page-range shards, 'default' for unsharded runs). Each entry holds: pass_id (lexicographically-ordered pass marker), cursor (provider cursor, e.g. JSON-encoded Iconik search_after), objects_processed (forward-only progress guard), modified_since (incremental filter frozen at pass start), completed_at (set when the shard drained its source — the next cycle wraps around to a fresh full pass only after the polling cadence elapses), and updated_at. A NEW job resumes each shard from its checkpoint instead of re-walking from page 1 (2026-06-11 re-scan treadmill).
Derived scheduling summary: mode, interval, next run, and last successful run.
Derived progress summary for API observability.
Whether a worker currently holds this sync's run lock.