Your Warehouse Reads The Bucket
Snowflake, Databricks, and BigQuery load from the storage the files landed in. No staging server sits between the sender and the stage, and no copy step runs before the load.
Land Partner Data Feeds In The Storage Your Pipelines Read
Files.com gives every vendor, client, and counterparty its own SFTP drop point under your domain, and writes each file into the S3, Azure, or Google Cloud storage your pipelines already read, decrypted and named the way the load expects. A webhook tells your orchestrator the moment it lands.
You cannot make a hundred outside senders change how they deliver. You can stop running a landing server, a sweep script, and a hand-provisioned account for each one.
Files land in your own bucket
A login and folder per sender
A webhook the moment a file arrives
Every Feed Is A Server, A Script, And A Person
Outside parties deliver the data your systems run on as recurring files: pushed over SFTP on their schedule, or left on their own server for you to fetch. Each one arrives in its own format, from its own IP, sometimes encrypted, and you have little leverage to change any of it.
Handled the usual way, every feed means an endpoint to patch, a sweep job to babysit, an account someone created by hand, and a missed pickup that nobody discovers until a load fails downstream and the dashboard is empty in the morning. On Files.com every sender is a folder and a credential, every file lands in your storage the moment it arrives, and the next sender joins the same pattern instead of becoming a project.
4,000+ organizations rely on Files.com every day
Real companies. Real file flows. Real results.
How The Intake Runs
Isolation per sender, files written to your storage, pulls from senders who will not push, and a hand-off your pipeline does not have to go looking for.
A Drop Point Per Sender
Every vendor, client, and counterparty gets its own login and its own folder under your domain, with an IP allow-list if their security team asks for one. Nobody sees another sender’s files, and the hostname they push to never changes when your storage does.
Straight Into Your Storage
A Remote Server Mount makes the sender’s folder a live window onto your own Amazon S3, Azure Blob, or Google Cloud Storage bucket. The file a vendor uploads over SFTP is written to your bucket as it arrives, and the pipeline reading that bucket never learns anything changed.
Pull From Senders Who Won’t Push
Some counterparties leave files on their own SFTP server for you to fetch. Files.com connects as the client on the schedule you set, with the server’s host key pinned and the credentials held in Files.com rather than in a script on someone’s machine.
Handed Off Without Polling
A webhook fires the moment a file lands, so your pipeline picks it up instead of sweeping folders every five minutes. Automations rename and route it on arrival, PGP decrypts an encrypted feed before it lands, and naming rules reject the file that would have broken the load.
What Reads The Files Next
The file is in your storage, named and decrypted. Everything downstream of that already works the way it does today.
Your Pipeline Tool Takes The Event
Fivetran, Azure Data Factory, or your own orchestrator starts a run when the webhook says a file arrived, with the sender and the path in the payload. The trigger is the arrival, not a clock.
Processing That Lives Inside Your Network
Where the loader runs on an internal server, the Files.com Agent delivers each arrival to that server over an outbound-only connection. Vendors reach a hosted endpoint; nothing in your network is exposed to them.
Data Teams Ingesting Partner Feeds Through Files.com
Nasdaq Data Link Brings Small Data Vendors Into Its Marketplace With Files.com—Without Running Its Own SFTP
A branded intake for suppliers without delivery infrastructure stayed in place through the Quandl acquisition and now supports roughly three million API transactions a day.
Read The Story
Spencer Gifts Replaced Its Legacy FTP Backbone With Files.com Without Changing Vendor SFTP Drops
The team staged the cutover before its seasonal freeze, with Files.com handling API transfers, alerts, and code-free archiving behind the existing partner interface.
Read The Story
Siemens Gamesa Moves From Microsoft IIS FTP to Files.com Without Moving Data Out of Azure
The replacement had to enforce Entra ID and MFA, delegate access administration, use dedicated IP addresses, and keep every file in Siemens Gamesa’s Azure tenancy.
Read The Story
Abcam Retired Its Self-Hosted FTP Servers With Files.com at MuleSoft’s Transfer Edge
A UK-locked landing zone now handles machine traffic from FTP-only counterparties while MuleSoft continues to orchestrate the integrations behind it.
Read The Story
“Files.com's strengths are simplicity, ease of use, and the cloud connectors. We don't have to invent custom infrastructure for every partner.”
Tommy Chapley
Senior Software Engineer, Equifax
“The integrations are the most valuable aspect. Files.com integrates with so many platforms — automating file transfers across all of them is straightforward.”
Joseph Alcorn
Director, Systems & DevOps, Point Loma Nazarene University
How It Compares
The three ways teams take in partner data today, and where the work ends up living.
A Landing Server And A Sweep Script
An SFTP box in the DMZ, an account created by hand per vendor, and a cron job that sweeps folders into the bucket. It works until the box needs patching, the script’s author leaves, or a vendor’s feed silently stops and nobody notices until a load fails downstream.
The Cloud Provider’s Endpoint Plus Glue Code
AWS Transfer Family or Azure’s native SFTP gets the file into a bucket and leaves per-sender isolation, decryption, renaming, alerting, and the audit trail as functions you write and run. Files.com is the assembled intake, in front of whichever cloud you use.
A Loader Per Partner
Each new source becomes its own integration, built to that sender’s format and schedule and owned forever. On Files.com a new sender is a folder, a credential, and the same arrival trigger everyone else uses.
Partner Data Feeds FAQ
What data and platform engineers ask before moving inbound feeds onto Files.com.
Yes. Files.com mounts your Amazon S3 bucket as a folder, gives each vendor an SFTP login scoped to their part of it, and writes every upload straight through to the bucket as it arrives. The vendor never holds an AWS credential and never sees the console. The same works for Azure Blob, Azure Files, Google Cloud Storage, and any S3-compatible store.
Yes. Each sender gets its own user, rooted in its own folder, with permissions that stop at that folder’s edge. Files.com grants access explicitly and only where granted, so a vendor sees its folder and nothing else. Per-user IP allow-lists and SSH keys add the controls a sender’s security team asks for.
Files.com fires a webhook when a file lands, carrying the path and the user that uploaded it, so your orchestrator starts the load on the event. Automations can also move the file into a per-run folder or rename it first, and the REST API lists exactly what arrived since the last run.
Yes. Attach your private key to the vendor’s folder in the PGP key manager and every encrypted file that lands there is decrypted on arrival. The decrypted file is what your pipeline reads, and each decryption is logged with the key and the file.
Yes. Files.com connects to the partner’s SFTP, FTPS, or FTP server as a client, pins its host key, and pulls on the schedule you set, then lands the files in your storage. The credentials live in Files.com’s credential manager rather than in a script, and a sync run appears in the same logs as everything else.
Folder naming and extension rules reject a file that does not match the pattern the pipeline expects, so the .xlsx a vendor drops into a .csv feed never reaches the loader. Expectations go further: they know which files are due from which sender by when, and open an incident when a feed is late, missing, or the wrong shape.
Give them a Files.com Inbox: a branded upload page, or an email address, under your domain. Whatever they drop there lands in the same folder structure the automated feeds use and fires the same triggers, so the pipeline does not care which path the file took.
Yes. A Files.com custom domain includes two dedicated IP addresses for inbound and outbound connections, so a partner that allow-lists your endpoint has fixed addresses to allow, and a partner whose server you pull from has fixed addresses to expect. Enterprise sites can bring their own IP ranges.
Files.com is the assembled intake: per-sender isolation, PGP decryption, renaming, arrival webhooks, alerting on missing feeds, and an audit trail, in front of any cloud. AWS Transfer Family is an SFTP endpoint on an S3 bucket, billed per protocol, and everything around it is Lambda you write and run.
Not unless you want one. With a Remote Server Mount, uploads pass straight through to your bucket and nothing is stored on Files.com. Teams that want a landing zone on Files.com first use a sync to move files onward and a retention rule to clear them once they have been loaded.
Give Every Sender A Drop Point, Keep Every File In Your Storage
Mount the bucket your pipelines read, hand each vendor a login and a folder, and let a webhook start the load. Start the 7-day free trial and land the first feed in your own storage today.
No credit card required • Free for 7 days • Live in minutes