SFTP API: What People Mean by It, and the Three Options That Exist
Search for an SFTP API and you find libraries, command-line tools, REST APIs, and managed platforms all described with the same phrase. Here is what each is, and which one you actually want.
Search for an "SFTP API" and you find libraries, command-line tools, REST APIs, and managed file transfer platforms, all described with the same phrase. That makes the answer more confusing than it needs to be.
SFTP does not include a standard HTTP API. It is a file transfer protocol that runs over SSH: you connect to a server, authenticate, and exchange SFTP messages to list directories and upload, download, rename, or delete files. When people ask for an SFTP API, they usually want one of three things: a library that lets an application speak SFTP, a way to automate SFTP transfers, or an HTTP API that gives access to files stored on an SFTP server. Each solves a different problem.
A library is the SFTP API for your language
If your application can connect directly to an SFTP server, your language's SFTP library is effectively the API. Paramiko in Python, JSch or SSHJ in Java, SSH.NET in C#, ssh2 in Node.js, phpseclib in PHP, Posh-SSH in PowerShell. Each turns SFTP operations into method calls: connect, authenticate, list a directory, upload or download, close.
The basic code is rarely the hard part. A real integration also verifies the server's host key, stores private keys and passwords securely, handles timeouts and interrupted transfers, retries without creating duplicate or partial files, confirms that uploads completed, logs usefully without exposing credentials, and surfaces errors to monitoring. Host-key verification is the one most examples skip: disabling it makes a quick example work and removes the check that confirms the application is talking to the intended server. A production integration pins the expected host key or validates it against a controlled known_hosts file.
Use a library when the transfer is a small part of an application you already operate and your team is prepared to own the connection details. The per-language posts cover each library with production-shaped examples: Python, Java, C#, Node.js, PHP, and PowerShell.
Automating SFTP from the command line
Not every transfer needs application code. For scheduled jobs and single-machine workflows, the OpenSSH sftp client in batch mode, scp for straightforward copies, and WinSCP's scripting mode and .NET assembly on Windows are enough. The OpenSSH client reads commands from a batch file with sftp -b commands.txt transfer-user@example.com, where the file holds cd /incoming, put report.csv, and bye. That works with cron, Task Scheduler, or any job runner.
Simple does not mean maintenance-free. The job still needs a securely stored SSH key, a trusted host key, correct file permissions, exit-code checking, logging and alerting, and a plan for partial or failed transfers. The common mistake is running an SFTP command on a schedule without checking its exit status: the scheduler reports that the script ran, and nobody notices the transfer failed. Treat a failed command as a failed job and send the result somewhere visible. The SFTP automation, scp, and WinSCP scripting posts cover each tool.
Use command-line automation for a focused transfer on a controlled machine when the workflow is small and unlikely to grow. Once it needs complex routing, several partners, detailed auditing, or sophisticated retries, a collection of shell scripts gets hard to manage.
An HTTP API in front of SFTP
This is what teams usually mean. Their partners use SFTP, and their own application is built around HTTPS, JSON, API keys, SDKs, and webhooks. They do not want SFTP credentials or SSH-specific behavior inside the application. The right architecture has partners and legacy systems continuing to use SFTP, the application using a REST API, and both reaching the same files. That takes more than a library: a platform that accepts SFTP connections while exposing those files through an HTTP API.
Files.com is built around this model. Files arrive over SFTP, FTP, FTPS, WebDAV, or AS2 and are reachable through the Files.com REST API, CLI, and seven official SDKs for Go, Java, JavaScript, .NET, PHP, Python, and Ruby, all generated from the same API definition, authenticating with an API key over HTTPS with typed errors, automatic retries, and resumable parallel transfers. A partner uploads over SFTP, a webhook tells your application the file arrived, and the application downloads and processes it over HTTPS. In reverse, the application uploads through the API and the partner downloads over SFTP. Neither side adopts the other's protocol, and SFTP concerns stay out of the application code.
Use an API-backed platform when file exchange is a recurring part of your business and you want it to behave like your other integrations: several partners, multiple protocols, centralized credentials and access control, webhooks instead of polling, detailed audit logs, SDKs for multiple applications, and consistent retry and error handling. The SFTP server hosting page covers the managed endpoint itself.
The API for a partner's SFTP server
The harder case is the SFTP server you do not control. You cannot add an API to someone else's server, and the partner may have no interest in changing how it works. A Files.com Remote Server Mount addresses this by connecting a folder on your Files.com site to the partner's SFTP server. To your application, the mounted server is another folder. Behind it, Files.com connects to the partner's server and passes operations through in real time.
Your application then uses the Files.com API, SDKs, or CLI to list files on the partner's server, download from it, upload to it, and rename or remove files as permissions allow. Files.com stores the SFTP connection details, can generate the SSH key pair itself so the private key never leaves the platform, and pins the partner's host key, disabling the connection if it ever changes. Your application keeps one HTTPS integration instead of implementing SFTP separately for each partner, and for scheduled or rule-based workflows a Sync or an Automation replaces the custom code altogether.
How to choose
The right approach depends less on the file operation and more on who owns the SFTP complexity.
| Approach | Best for | You are responsible for |
|---|---|---|
| SFTP library | SFTP inside an existing application | Keys, host verification, retries, errors, and connection handling |
| Command-line tool | Simple scheduled or one-off transfers | Machine configuration, keys, exit codes, logging, and alerts |
| REST API over SFTP files | Recurring partner integrations and multi-protocol workflows | Your HTTPS integration and business logic |
| Remote Server Mount | Adding API access to a partner-managed SFTP server | API usage, while the platform manages the SFTP connection |
A library gives the most direct control. Command-line tools fit small, contained jobs. An HTTP API is the better fit when file transfer is part of a broader integration strategy.
Frequently asked questions
Is there an SFTP API?
SFTP does not include a standard HTTP API; it is a protocol that runs over SSH. You can use an SFTP library from application code, automate transfers with command-line tools, or use a platform that exposes SFTP-accessible files through a REST API.
How do I upload a file to an SFTP server from code?
Use an SFTP library for your language, such as Paramiko, SSHJ, SSH.NET, ssh2, phpseclib, or Posh-SSH. Authenticate securely, verify the server's host key, upload the file, and handle failures. For important workflows, upload to a temporary filename and rename it only after the transfer completes.
How can my application access SFTP files through an API?
Use a platform that accepts SFTP while exposing the same files through a REST API and SDKs. Partners keep using SFTP, and your application uploads, downloads, and lists files over HTTPS.
Can I put an API in front of a partner's SFTP server?
Yes. A Files.com Remote Server Mount connects a folder on your site to a partner's SFTP server, and your application operates on that folder through the Files.com API, SDKs, or CLI while Files.com manages the SFTP connection details.
Does an SFTP REST API replace SFTP?
No. Partners and legacy systems keep using SFTP while modern applications use HTTPS and an API. Both interfaces operate on the same files.
Keep reading
- Python SFTP: Paramiko, pysftp, and a Way That Needs NeitherPython SFTP with working code: uploading, downloading, and listing files with paramiko, why to skip pysftp, and a third way where Files.com makes the SFTP connection so the script never speaks the protocol. SSH keys, host verification, and running it from cron.
- SFTP Automation: A Cron-Safe Script, and the Way That Needs No ScriptSFTP automation done properly: the sftp -b batch file, a bash script that is safe to run from cron (locking, logging, upload-then-rename, real exit codes), lftp for mirroring, and the way that needs no script, where Files.com makes the SFTP connections and runs the schedule with retries, logs, and alerts.
- Java SFTP: Working JSch and sshj Examples, Plus the Way That Skips BothJava SFTP with complete code: JSch from the maintained fork, sshj for new projects, host key verification done right, and a third way where Files.com makes the SFTP connection so the JVM never speaks the protocol. Keys, known_hosts, and credentials in a deployment.
- Node.js SFTP: ssh2-sftp-client, the OpenSSH Client, and a Way Without EitherNode.js SFTP with working code: ssh2-sftp-client with a real host key check, the OpenSSH sftp binary driven from Node, and a third way where Files.com makes the SFTP connection so the process never speaks the protocol. Keys in a container and failing loudly on a schedule.
- S3 to SFTP and SFTP to S3: Three Ways to Connect a Bucket and an SFTP ServerS3 to SFTP in both directions: a script through a middle machine, an SFTP endpoint in front of the bucket, and Files.com mounting the bucket and the partner's SFTP server so a scheduled Sync moves files with no code, no staging disk, and one audit trail.