SFTP to HTTP POST

Plenty of partners can only send files over SFTP, but your application would much rather receive an HTTP request than babysit an SSH inbox. The traditional bridge is an SFTP server writing files to disk, a cron job scanning that directory, and a script that POSTs each file to your endpoint and deletes it. FTPasHTTPS removes all three: it terminates the SFTP session and pipes the upload directly into a single HTTPS POST, in one streaming hop.

How SFTP-to-HTTP-POST works

1. A client connects over SFTP (SSH key auth), FTPS or FTP and runs a STOR (upload) command.
2. FTPasHTTPS opens an HTTPS POST to your configured endpoint and streams the incoming bytes straight into the request body.
3. Optional inline transforms (CSV→JSON, JSON→XML, schema validation, compression, PGP) run mid-stream before the bytes reach your endpoint.
4. Each POST is signed with HMAC-SHA256 so your endpoint can verify it came from FTPasHTTPS.
5. Your endpoint returns 200 and the client receives 226 Transfer complete; a 5xx maps to 451 Action aborted so the client retries.

Configuration + example POST

An HTTP POST target on a server is a small JSON config. You supply the endpoint URL, any headers your API needs, and whether to sign the request:

# HTTP POST target for an SFTP server
{
  "protocol": "sftp",
  "auth": { "type": "ssh-key" },
  "forward": {
    "type": "http",
    "url": "https://api.example.com/v1/ingest",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer ${API_TOKEN}",
      "X-Source": "partner-dropbox"
    },
    "sign_with": "hmac-sha256"
  }
}

When a client uploads orders.csv, your endpoint receives the raw bytes in the body of a signed POST:

# POST https://api.example.com/v1/ingest
Content-Type: application/octet-stream
Authorization: Bearer ${API_TOKEN}
X-FTPasHTTPS-Signature: sha256=9f1c4e2a7b80...
X-FTPasHTTPS-Event: file.uploaded
X-FTPasHTTPS-Filename: orders.csv
X-FTPasHTTPS-User: partner-dropbox

# <-- raw file bytes stream into the request body -->
order_id,sku,qty,price
A-1001,WIDGET-RED,4,12.50
A-1002,WIDGET-BLUE,2,12.50

FTPasHTTPS vs. the DIY SFTP + cron pipeline

Concern	DIY SFTP server + cron + script	FTPasHTTPS → HTTP POST
Delivery to your API	A script you write and maintain	Native — upload is the POST body
Files on disk	Written to a volume, then deleted	Never touch disk — streamed
Latency to endpoint	Up to the cron interval (minutes)	Streams during the upload
Request authenticity	Roll your own signing	HMAC-SHA256 signed out of the box
Retries on error	Hand-rolled, often missing	Exponential backoff + dead-letter queue
Audit trail	Scattered across syslog	Full audit log per transfer
Protocols	Usually SFTP only	FTP, FTPS and SFTP

When to use it (and the limits)

Reach for SFTP-to-HTTP-POST when a partner insists on SFTP but your ingestion path is an HTTP endpoint, when you want the file in your API the moment it lands, or when you would rather not own an internet-facing SSH daemon. SFTP (SSH key auth) and the inline transforms begin on the Professional plan (€49/server/month: 10,000 transfers, 50GB). The Free and Starter tiers are FTP/FTPS only, so you can prototype the same POST contract over FTPS before a partner cuts over to SFTP.

A few limits to keep in mind: forwarding is per-file at upload time, so this is not a batch replay tool for files you already have. The POST body is one streamed upload — if you need multipart bundling, do it in your endpoint. And throughput is bounded by your plan's monthly transfer and size caps: 10,000 transfers / 50GB on Professional, 50,000 / 250GB on Enterprise.

Verifying the signature and handling failures

Every POST carries an X-FTPasHTTPS-Signature header containing an HMAC-SHA256 of the request body keyed with your server's signing secret. Recompute the HMAC on your side and compare it in constant time before trusting the payload — anything that fails the check is not from FTPasHTTPS and should be rejected. Because the signing secret never leaves your dashboard and the file never lands on a shared volume, there is no ingestion inbox to harden or sweep.

If your endpoint is briefly down or returns a 5xx, the POST is retried with exponential backoff; if it keeps failing it lands in the dead-letter queue rather than being silently dropped, and the SFTP client sees 451 Action aborted so it knows to resend. Every attempt — success or failure — is written to the audit log, giving you one place to confirm whether a given file reached your API and exactly when.

Frequently asked questions