Skippr Docs

Appearance

How SFTP Defines the Raw Data Contract ​

July 2026

For SFTP, raw data is the content of the files that match the agreed remote path, not a generic promise about everything an SSH user can log in and see.

Short Answer ​

The raw data contract for SFTP is the set of files matched by one remote_path or glob on the server. Skippr downloads those files from the configured host and user, so the raw layer is whatever content appears at that agreed remote location, with lineage grouped under the sftp.{filename} namespace.

That means the folder or pattern is the contract. If the source path is /data/orders/*.json, raw data is the JSON order exports that land there. If the partner instead publishes nightly CSV files under /exports/orders-*.csv, that file naming pattern defines the contract. The important thing is that the remote path and the file family stay stable enough that another engineer can predict what tomorrow will look like.

Why Teams Struggle with This ​

SFTP sources become brittle when teams describe the vendor relationship instead of the actual file boundary. The raw contract is never “whatever the partner sends.” It is the concrete path and filename pattern Skippr reads.

  • The remote_path value is the real raw boundary, whether it names one file, one folder, or a glob pattern.
  • Password versus private-key authentication changes security posture, but it does not change the file contract itself.
  • A login that can authenticate but cannot list or read the selected location still leaves you with no usable raw source.
  • If the partner changes naming conventions without warning, the file contract changed even if the SFTP server stayed up.

How Skippr Handles It ​

Skippr keeps SFTP grounded in the real handoff surface: host, username, auth method, and remote path. That is the right level of detail for a source whose real interface is a folder and a file pattern rather than a database schema.

Using the filename namespace is also helpful in practice. Downstream teams can see which files produced which raw records instead of treating the SFTP drop as an anonymous blob of imported data.

  • Reads files from one SFTP host and a specific remote path or glob.
  • Supports password auth or preferred SSH private-key auth.
  • Uses the namespace sftp.{filename} so file-level lineage stays visible.
  • Fits existing vendor and legacy file-drop workflows without requiring a second transfer service.

What the First Useful Version Looks Like ​

The first useful version is one remote path pattern and one file family that arrives predictably. That gives you a chance to judge the stability of the handoff before you widen the feed.

If the file drop is already chaotic, do not call it a solid raw contract yet. SFTP can be a dependable source, but only when the remote path really means one understandable dataset.