Source connector

SFTP Bulk connector

SFTP Bulk integration for databases, warehouses and BI tools

Bulk file drops delivered over SFTP. Datrise captures SFTP Bulk entities such as files, directories, rows, file batches, modification timestamps and file formats, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The SFTP (SSH File Transfer Protocol) file pickup — vendor-agnostic bulk file source authenticates with username / password, incremental runs key on File `mtime` (SSH_FXP_ATTRS modification timestamp) and/or a filename pattern (e.g. a date-stamped name like `export_2026-09-02.csv`) used to detect files new or changed since the last successful pickup.

Of the 6 objects, 6 sync as upserts keyed on the primary key and 0 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `sftp_bulk_files`) with a schema derived from the SFTP Bulk API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the SFTP Bulk pipeline page, and join the waitlist to get the SFTP Bulk connector with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What SFTP Bulk data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
files	sftp_bulk_files	Upsert by primary key, incremental on updated-at
directories	sftp_bulk_directories	Upsert by primary key, incremental on updated-at
rows	sftp_bulk_rows	Upsert by primary key, incremental on updated-at
file batches	sftp_bulk_file_batches	Upsert by primary key, incremental on updated-at
modification timestamps	sftp_bulk_modification_timestamps	Upsert by primary key, incremental on updated-at
file formats	sftp_bulk_file_formats	Upsert by primary key, incremental on updated-at

SFTP Bulk API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	SFTP (SSH File Transfer Protocol) file pickup — vendor-agnostic bulk file source
Authentication	username / password — SFTP servers accept username/password over the SSH transport, but in production most file-drop integrations instead use an SSH public/private key pair registered in the server's `authorized_keys`.
Pagination	none — Not applicable; the connector lists a directory and downloads each matching file once over SSH, there is no page or cursor concept.
Rate limit	Not published
Incremental cursor	File `mtime` (SSH_FXP_ATTRS modification timestamp) and/or a filename pattern (e.g. a date-stamped name like `export_2026-09-02.csv`) used to detect files new or changed since the last successful pickup — There is no protocol-level cursor since SFTP is a filesystem transport, not an API; incremental behavior is only as reliable as the naming and timestamp discipline of the system producing the files.
Webhooks	No
Bulk export	Yes — Native bulk file pickup — whole CSV, JSON (array or newline-delimited), and Parquet files fetched per file over SFTP
Deletes detectable	No

Official API reference

What bites when replicating SFTP Bulk

File `mtime` comes from the SSH `SSH_FXP_ATTRS` struct and is only as reliable as the producing system's clock; a re-uploaded file with an unchanged name but a bumped `mtime` is the only generic way to detect an update.
Parquet's column footer metadata lives at the very end of the file (not streamed like NDJSON or CSV), so a connector must fully download each `.parquet` file before it can parse a single row.
The IETF `draft-ietf-secsh-filexfer` was never finalized as an RFC; in practice OpenSSH's SFTP subsystem implements protocol version 3, so version-6-only attributes are not universally supported.
SFTP carries no delete or tombstone signal; the only generic (if unreliable) way to infer a deletion is a shrinking row count between two full-snapshot files, e.g. going from 10,000 to 9,998 rows.

Compare this against every other documented API

Popular destinations for SFTP Bulk

Choose a destination below to open the ready pipeline page.

A
Airtable
Relational spreadsheet destination for ops and go-to-market teams.
View pipeline
A
Amazon Athena
Serverless SQL over S3 data lake tables.
View pipeline
A
Amazon DynamoDB
Serverless key-value and document store on AWS.
View pipeline
A
Amazon QuickSight
AWS serverless BI with SPICE and embedded analytics.
View pipeline
A
Amazon Redshift
AWS petabyte-scale warehouse with Spectrum.
View pipeline
A
Amazon S3 Data Lake
Object storage landing zone for parquet and snapshots.
View pipeline
A
Apache Superset
Open-source BI for SQL exploration, charts, and dashboard publishing.
View pipeline
A
Azure Data Lake Storage
ADLS Gen2 object storage for analytics workloads.
View pipeline
A
Azure Synapse
Microsoft analytics workspace with SQL pools.
View pipeline

SFTP Bulk connector FAQ

What SFTP Bulk data does the connector extract?: 6 objects: files, directories, rows, file batches, modification timestamps and file formats. Each lands in its own table with types preserved; history-style objects (0) load as append-only streams.
Is the SFTP Bulk integration incremental?: Yes. After the initial full load, every run reads only records changed since the last watermark (updated-at or event timestamp) and applies an upsert or an append depending on the object.
Where can I load SFTP Bulk data?: Into 43 destinations: relational databases, cloud warehouses, data lakes, spreadsheets and BI tools. Each SFTP Bulk → destination pair has its own page with the object-to-table mapping.

Related sources

Other sources in the same category, each with its own connector page.

Early access

Launch your SFTP Bulk pipeline with guided onboarding

Join the waitlist to get priority access for SFTP Bulk integrations with guided setup, schema-aware mapping, and production-grade incremental sync.