For healthcare document intake, choose a REST API when the sender is software that can react to errors file by file, and SFTP when the sender is a legacy system or partner that can only drop batches. A REST API reports each failure at once; SFTP is simpler to start but fails quietly unless watched.
REST API and SFTP document intake compared
REST API intake and SFTP intake both move scanned pages from the place they arrive to the system that processes them. A REST API takes one HTTP request per document and answers at once. SFTP, the SSH File Transfer Protocol, lets the sender copy files into a folder that a job picks up later.
The two channels differ most in what the sender learns and when. An HTTP upload returns a status code within the same connection, so the sending program knows whether the file was accepted. A file copied over SFTP has only landed in a folder. Whether the processing system later read it, rejected it or ignored it is a separate question that the transfer itself does not answer.
The table below compares the two on eight criteria. Values describe a typical setup, not any one product.
| Criterion | REST API intake | SFTP intake |
|---|---|---|
| Latency | Seconds: the file is handed over as soon as it exists | Minutes to hours: depends on how often the pickup job runs |
| Error feedback | Immediate, per document, as an HTTP status and message | None from the transfer; errors appear later in a report or log, if at all |
| Partial files | Rejected by the request if the body is incomplete | Possible: a job can read a file still being written |
| Duplicate handling | Needs an idempotency key or a content hash on the receiving side | Needs file naming rules and a hash check on the receiving side |
| Sender skills | A developer who can call HTTP and handle responses | Anyone with an SFTP client or a scheduled script |
| Setup | API keys, client code, retry logic | An account, an SSH key and a folder layout |
| Monitoring | Error rates and response times per request | Folder counts, file ages and a check that each file produced output |
| Fits best | Software that creates documents one at a time | Nightly batches from systems that cannot call an API |
Two questions settle most choices. First, can the sending system run code that reads an HTTP response and retries on failure? If not, use SFTP. Second, does anyone need to know within minutes that a document failed? If yes and the sender can run code, use a REST API. If the answer to both is no, SFTP with good monitoring is enough.
Retries on the API side need care, because a client that times out may resend a file the server already stored. The guide to retries and idempotency keys for document uploads covers how to make a repeated upload safe.
When is SFTP the better choice for healthcare document intake?
SFTP is the better choice for healthcare document intake when the sender cannot run custom code, sends documents in a nightly batch, or is a partner whose own rules allow only file drops. Many older practice systems and scanning stations can export a folder of PDFs on a schedule but cannot call a web service.
SFTP also suits batches where speed does not matter. A billing service that receives a day of scanned EOBs from a clinic after close of business gains nothing from per-second delivery, because nobody will work the queue until morning. A file drop at night and a pickup job before the team arrives fits that rhythm.
Partner constraints are the third reason. A clearinghouse, a scanning vendor or a hospital IT team may already run SFTP for other exchanges and may refuse to build against a new API. Matching their channel can be the difference between starting next week and starting next quarter.
Faxed documents often take a similar route, landing as image files in a folder from a fax server. The guide on how to process medical faxes automatically covers that intake path.
Which intake channel is easier to secure, REST API or SFTP?
Neither REST API intake nor SFTP intake is secure by default; both can be locked down well. A REST API for documents should run over HTTPS, meaning TLS, which the IETF TLS 1.3 specification, RFC 8446 says is designed to prevent eavesdropping, tampering and message forgery. SFTP runs inside SSH, which provides its own encrypted channel.
The IETF SSH architecture, RFC 4251, describes the SSH transport layer as providing server authentication, confidentiality and integrity. The SSH authentication protocol, RFC 4252, makes public key authentication the only required method and says implementations should support passwords. In practice, SFTP accounts for document intake should use keys only, with password login turned off.
For an API, the common controls are a secret key or token per sender, rotation of those keys, and TLS on every request. For both channels, an IP allowlist narrows who can connect at all. The difference is in the audit trail. An API can log each request with the key that made it and the document it created. An SFTP server logs logins and file operations, but tying a file in a folder back to the record it became takes extra work.
The HIPAA Security Rule, in the eCFR text of 45 CFR 164.312, lists audit controls and transmission security among its technical safeguards and labels encryption in transit as addressable. Whether a given setup meets those standards is a question for your compliance team. Encryption in transit and at rest, and the business associate agreement (BAA) a vendor must sign, are covered in the guide to encryption at rest and in transit for PHI.
The SFTP intake blind spot: silent failures
The main weakness of SFTP intake is silent failure: a file never arrives, arrives empty, or arrives and is never picked up, and nobody is told. The transfer protocol reports on copying bytes, not on what happens next, so a broken nightly job can go unnoticed for days.
Several failure patterns repeat. The sender's scheduled export stops after a password or key change, and the folder simply stays empty. A file is read while still being written, so the job processes half a document. A pickup job crashes on one bad file and skips the rest of the batch. A file name collides with yesterday's and overwrites it.
SFTP was never published as a final RFC. Its expired IETF draft, version 02 of the SSH File Transfer Protocol draft on the IETF datatracker, defines a rename operation and notes that even a close can fail on some server platforms. Because the text is a draft, check what your own SFTP server supports. One pattern built on rename is to upload under a temporary name and rename the file when the upload completes, so the pickup job ignores anything still in progress.
Monitoring closes the rest of the gap. Alert when no file arrives in the expected window. Alert when a file sits unprocessed longer than one pickup cycle. Count files in and records out every day and compare them. A batch of 40 fictional EOB pages that becomes 38 records is a problem to chase that morning, not at month end.
Whichever channel you pick, it only delivers documents. What happens to the extracted values afterwards is a separate design, covered in the guides on mapping extracted fields to an EHR and on EHR integration versus RPA for data entry. Schema Care offers no API, SDK, webhooks, FHIR output, 835 or 837 output, and no SFTP drop. It scores each field it reads and holds the uncertain ones for a person, which the review workflow on the homepage walks through.