Skip to main content

Fivetran

Fivetran's SFTP connector can read files from a Files.com folder and load their data into a supported destination. Files.com provides the source endpoint and the intake around it: partners submit through their own accounts, files are prepared where necessary, and Fivetran reads the resulting input. Fivetran owns the connector's extraction and destination-table behavior.

This uses Fivetran's SFTP connectorExternal LinkThis link leads to an external website and will open in a new tab, rather than a separate Files.com connector in Fivetran. It fits a pipeline whose upstream senders cannot all deliver directly to the warehouse or use Fivetran's preferred file layout.

SFTP Source

Create a dedicated machine account with SFTP enabled and listing and download access to the prepared source folder. Fivetran's credential should be separate from the accounts partners use to submit files.

Configure the Fivetran connection with your Files.com hostname, port 22, and that username. Use the configured custom domain if the connection requires your site's dedicated destination addresses. The SFTP connection settings explain the network and authentication requirements.

For key authentication, install the connector's public SSH key on the Files.com user. Fivetran supports a managed key or a customer-supplied key; with a customer-supplied key, the private key belongs in Fivetran's credential configuration. Compare the server host key shown during connection setup with the Files.com host-key reference.

Set the connector's folder path as the SFTP account sees it. A configured client root folder can present the prepared source folder as /. If Files.com restricts source addresses, allow the addresses Fivetran specifies for that connection.

Partner Intake and File Selection

Keep partner submissions outside the folder Fivetran scans until any required preparation finishes. For example, partners can upload encrypted exports to their individual intake folders while an Automation publishes usable files under a shared ready folder. The connector needs access to the prepared result, not every sender's original files.

Fivetran's setup offers Magic Folder and Merge Mode strategies. Select the strategy, subfolder handling, and file patterns around the tables the pipeline should produce. A broad pattern can include files that were retained for another purpose, so keep archives and rejected input outside its selection.

Agree on whether source files have new names for each delivery or are replaced in place. Fivetran's file-handling and primary-key choices determine how updates affect the destination. A Files.com archive does not determine whether Fivetran appends, replaces, or updates table rows.

Decryption and Formats

Fivetran can decrypt PGP files through its connector configuration. Alternatively, Files.com can decrypt the source files and present the prepared output. Choose where the private key is managed and give the connector the file form that choice produces; do not configure both sides to expect an encrypted input after Files.com has already decrypted it.

Use a transformation only when the source needs a different supported layout. The connector still needs the correct file type, encoding, delimiter, and other parsing options. Renaming an extension alone does not convert a file's contents.

Initial Load and Later Deliveries

Run Fivetran's connection test with a representative file in the actual source folder. Verify the expected file selection and destination rows, then check a later delivery using the naming and update pattern the recurring feed will use. This establishes more than whether the connector can sign in.

Use SFTP Logs for Files.com connection failures and Fivetran's sync history for parsing or loading failures. An Expectation can detect a missing upstream feed even when the connector has nothing new to load.

Keep source files for the recovery period your team needs, and ensure the connector's selection excludes that archive. Before replaying retained files, check Fivetran's handling of previously loaded input so recovery does not unintentionally add the same records again.