A destination write is a separate, authorized operation.
Destinations
File destinations
The export worker names file destinations s3, google_cloud_storage, and azure_blob_storage. The HTTP route POST /api/w/:workspaceId/agent-runs/:runId/file-destination-export with { connectionId } is documented in the API as the S3 file export queue. It returns 202 with accepted, destinationBindingId, jobId, and jobType connection.destination.file_export when queued. Queued is not written.
Record destinations
Record destinations in the worker are postgresql and mysql. POST /api/w/:workspaceId/agent-runs/:runId/record-destination-export queues a PostgreSQL record export. PostgreSQL destination fields include host, port, database, user, password, schema, table, and optional dbt flags. dbtWriteEnabled stays false unless an owner or admin has an operator-approved mutation. MySQL destination write mode in the spec is append, and tableName is required.
Vector destinations
POST /api/w/:workspaceId/agent-runs/:runId/vector-destination-export queues an export for Qdrant, Pinecone, or Weaviate. You must attest targetAlreadyUsesModel: true with the provider id, model id, and dimensions. That attestation does not provision the index. A read probe never stands in for file.write, vector.write, or destination.dlt_write. Those write checks are explicit readiness operations on a destination connection.
Catalog backing
Catalog backing can be toggled only on a destination whose connector supports writing a document blob. Today that is S3, GCS, and Azure Blob. Turning it on does not copy existing documents.