Landing In Your Own Storage
A Remote Server Mount writes each customer’s uploads straight into your Amazon S3 or Azure bucket, per-customer prefix and all. The pipeline reading that bucket never learns a file came through Files.com.
Files.com gives each customer a folder and credential under your domain, provisioned from your application, and hands every arrival to your processing the moment it lands. Results go back to the same place, and the record of who took what writes itself.
Your service runs on files customers send you. Doing intake on your own SFTP server or over email means engineers minding file plumbing instead of the product, arrivals nobody notices, and an integration project for every new customer.
A processing business has one interface with its customers that never goes away: the file. Exports, transaction feeds, rosters, scans, and datasets come in; results, reports, and deliverables go out. Each customer needs a place only it can see for both directions, whether a person uploads once or a system pushes every night.
Built by hand, that place is an account someone creates, a firewall rule someone negotiates, and a folder someone watches. On Files.com the place is provisioned by your own code, the arrival is an event your pipeline consumes, and a file in the right folder is the whole handshake.
Real companies. Real file flows. Real results.






















Isolation per customer, provisioning from your application, an event on arrival, and a record afterward.
Each customer gets a login rooted in its own folder under your domain. A person uploads once through the browser or a system pushes nightly over SFTP; either way the file lands in that customer’s space and nowhere else. Results go back to the same place.
The REST API and SDKs create the user, the folder, and the permissions when a customer signs, and retire them when it leaves. Onboarding a customer becomes a step in your own workflow, not a ticket to whoever runs the file server.
A webhook fires the moment a file lands, with the customer and the path in the payload, and Automations rename, move, or decrypt it first. Your pipeline runs on the event. File placement is the contract: a file here means submitted, a file there means processed.
Every upload and download is in the audit log, so when a customer asks whether its results were collected, the answer is a lookup. Retention rules age files off the exchange once they have been processed.
Where the files land and who is doing the processing decide the shape. The customer’s experience is the same in all three.
A Remote Server Mount writes each customer’s uploads straight into your Amazon S3 or Azure bucket, per-customer prefix and all. The pipeline reading that bucket never learns a file came through Files.com.
The Files.com Agent carries each customer upload to an internal processing server over an outbound-only connection and returns the result to the customer’s folder, with no inbound port and nothing exposed.
A SaaS vendor calls Files.com as its file tier: the API creates a tenant’s folder and download links from application code, and a child site under the tenant’s own brand gives the customers who need an SFTP endpoint one that looks like your product.
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
The UK operation replaced internally hosted transfer servers while preserving the FTP and SFTP access its clients used for orders and product updates.
Read The Story
Files.com gave outside vendors a simple way to exchange enormous creative assets while keeping identity, encryption, compliance, and control with Makino’s IT team.
Read The Story
Institutional customers move critical financial data through an isolated, auditable exchange that e-Builder delivers as part of its own software.
Read The Story
“Great REST API for automating everything, well documented. Every SFTP use case we have is covered, with encryption end-to-end.”

“A security-first approach, granular permission model, and detailed audit logging. Easy to enforce least-privilege access across multiple sites.”

The three ways customer files come in today, and what each one costs the team that should be building the product.
Engineers minding file plumbing instead of the product: firewall negotiations for every client, accounts created by hand, arrivals nobody notices, and a security review re-answered for each new logo.
Client data arriving as attachments or through a collaboration-suite guest link, downloaded by a person and re-uploaded into processing. It caps intake at headcount and leaves no per-file record.
Storage, permissions, multi-tenancy, notifications, and an audit trail built into the product and maintained forever by the team that was supposed to be building the product.
What platform, integration, and engineering teams ask before moving customer intake onto Files.com.
Create a user per client on your Files.com site, rooted in its own folder under your domain. The client uploads over SFTP or in a browser, a webhook fires when the file lands, and an Automation moves it into the folder your pipeline watches or lands it in your own cloud storage. Results written back to the client’s folder are picked up the same way.
Yes. The Files.com REST API and the seven SDKs create users, folders, permissions, and API keys from your own code, so a customer signing up in your product gets its intake folder in the same transaction. Terraform manages the same objects as code, and SCIM provisions your internal staff from the directory.
A webhook posts to your endpoint the moment a file lands, with the path and the uploading user, and a folder notification emails the account team or posts to Slack or Teams. The event, rather than a polling loop, starts your processing.
Yes. The Files.com Agent runs on a server inside your network and connects outbound to Files.com, so each client upload is carried to the internal processing folder and the result is carried back, with no inbound port, no VPN, and no DMZ host.
Give each client a folder and login on your Files.com site, or a branded Inbox for the client that will only use a browser. Files.com offers a HIPAA Business Associate Agreement, and every upload and download is recorded in the immutable audit log with the user, the file, and the time, so the question of who took a result set is a lookup.
Yes. Your application calls the API to store and retrieve each tenant’s files, mint download links, and create per-tenant folders, and the surfaces a customer sees run under your own domain and branding. Customers whose systems push over SFTP connect to an endpoint with your name on it.
Yes. A Remote Server Mount makes each customer’s folder a window onto your own bucket, so uploads are written to Amazon S3, Azure Blob, or Google Cloud Storage as they arrive, under the per-customer prefix your pipeline expects. Nothing is stored on Files.com unless you want it there.
Yes, through child sites: each client gets a fully separate site under its own domain, users, and settings, administered from the parent account. Child sites require a qualifying plan and are billed under the parent, and reselling Files.com commercially requires a reseller agreement, which is a conversation with sales.
Move the exchange to a Files.com site under your own domain, where each client has a folder and a login of its own and your staff sign in through single sign-on. Clients never become identities in your Microsoft tenant, and a mount or sync keeps the files in SharePoint where your staff work if that is where they belong.
Create the intake when the customer signs, take the event when a file lands, and return results to the same place. Start the 7-day free trial and provision the first customer from the API today.
No credit card required • Free for 7 days • Live in minutes