Docs

How it works

A protocol gateway sits between two worlds. On one side, a source speaks SFTP. On the other, a sink speaks HTTPS. The gateway translates between them.

The path of an upload

1. Source connects over SFTP. A source opens an SFTP connection to the gateway and offers an SSH public key.
2. The gateway resolves a tenant. The public key and its fingerprint are looked up in the tenant store. A match identifies one tenant and the delivery rules attached to it. An offered key with no match is refused before any file is accepted.
3. Bytes are delivered to the sink. As a file is written over SFTP, the contents are delivered to the tenant’s configured HTTPS endpoint as a request. The sink responds over HTTP, and that result determines whether the upload is treated as delivered.

Why a gateway

Many systems still emit data over SFTP. Real estate CRMs publishing REAXML feeds are one example. The receiving service, by contrast, is usually an HTTP API. Running and securing an SFTP server to bridge the two is operational work: host keys, account management, disk handling, and exposure on a well-known port.

The gateway removes that work. A source keeps its existing SFTP workflow. The receiving service handles plain HTTPS requests. No SFTP server runs on the receiving side.