Ask any edtech implementation team where their onboarding time goes and the answer is rostering. Clever and ClassLink cover the districts that use them; everyone else sends files. Usually that is most of them: a nightly CSV export from the SIS, dropped on an SFTP server, in a layout that is almost, but not exactly, like the last district's.
This guide covers what those files look like, where the OneRoster CSV standard helps and where it stops helping, and what a reliable nightly ingestion pipeline needs to survive a school year.
What districts actually send
In the best case, the district exports OneRoster CSV: a zip containing a fixed set of files (users, orgs, classes, courses, enrollments, and a manifest) with standardized columns and identifiers that reference each other. When you get real OneRoster output, ingestion is close to deterministic, and the spec gives you referential integrity checks for free: every enrollment should point at a user and a class that exist in the same delivery.
In the common case, you get something else: a custom export from PowerSchool, Infinite Campus, Skyward or a state system, with the district's own column names, its own ID scheme, and sometimes one merged file instead of the OneRoster set. Two districts running the same SIS still produce different files, because exports are configured locally. That is why "we support OneRoster" and "we can ingest any district's roster" are different claims, and the second one is what sales ends up promising.
The nightly cadence changes the engineering problem
Roster files are not a one-time migration; they arrive every night, and the platform is expected to reflect them by morning. That means the pipeline needs three things a one-off importer does not: automatic pickup (usually polling the district's SFTP drop or hosting one per district, see our SFTP automation guide), diffing (yesterday's file against today's, so a vanished student becomes a deactivation, not a delete-and-recreate), and quiet-failure detection, because the worst outcome is a feed that stops arriving and nobody notices until a teacher calls.
Validation rules that save you in October
Districts change their exports mid-year: a column gets renamed after an SIS update, the school year rolls over and every class ID changes, a bulk re-enrollment doubles the file size. Each of those should be caught before it reaches your application. The checks that earn their keep: mandatory columns present, row count within a tolerance of the previous delivery, identifiers unique, references resolvable, and dates inside the current school year. When a check fails, the pipeline should flag the change and hold the delta for review instead of failing silently or, worse, applying it.
School year rollover deserves its own plan. The first delivery of the new year legitimately violates every tolerance you set: thousands of enrollments end, thousands begin, and grade levels shift. Treat rollover as a known event with a relaxed rule set, not as an anomaly, or your support inbox will fill on the busiest week of the year.
Mapping district files to one schema
Whether the input is OneRoster or a custom export, your application wants one shape. The pattern that scales is per-district mappings against a single internal schema: learn the mapping from the district's first file, review it with a human, then run it automatically on every nightly delivery. It is the same discipline we describe in automatic CSV mapping, applied to a domain where the sender is a school district IT office with two hundred other things to do, so asking them to change their export format is rarely a winning move. Meet the file where it is.
Build, buy, or both
Rostering hubs solve this for districts inside their networks. For everyone outside, edtech vendors either staff implementation people to babysit SFTP drops and mismatched columns, or run the ingestion on a platform built for recurring client files. FileFeed does the second: each district gets an SFTP drop or sends email attachments, the mapping to your schema is learned once and approved by you, every nightly file is validated with the change flagged instead of silently applied, and clean JSON lands on your API by morning. The fastest way to evaluate it is with a real district file: send one and it comes back mapped the same day.
Related resources