Skip to main content

Systems Integration Glossary for K-12 Data Staff

This glossary translates the terms you'll hear from vendors, IT staff, and auditors into plain English. You don't need to become an engineer to use it — you need enough footing to ask a sharp question, spot a vague answer, and know when to loop in someone more technical.

Each entry answers three things: what it is, why it matters to a school district, and a real-world example. This is the foundation for SDLA's broader Systems Integration Solutions library — later guides on rostering, LTI, and vendor onboarding will link back here instead of re-explaining terms.

Draft for review. This is a working draft circulated for member and staff input before publication. Comments and corrections welcome.

Core Data & Connection Concepts

  • API (Application Programming Interface) — A defined way for two pieces of software to talk to each other. Think of it as a restaurant menu: your SIS doesn't need to know how the kitchen (another system) works internally, it just orders from a fixed list of what's available. When a vendor says "we have an API for that," it means another system can request or send data to them in a structured, predictable way, instead of someone manually exporting a spreadsheet.
  • Endpoint — One specific "item on the menu" within an API — a single address that does one job, like "get a list of today's absences" or "submit a new enrollment record." A vendor's API is usually made up of dozens of endpoints.
  • Integration — The general term for connecting two systems so data flows between them automatically, instead of someone re-typing it. Rostering your SIS into a learning platform is an integration.
  • Roster / Rostering — The list of students, staff, and their class or course enrollments, and the process of sending that list from your SIS to another system (an LMS, an assessment tool, a communication platform). Almost every integration problem you'll encounter traces back to a rostering issue.
  • Sync (Synchronization) — Keeping two systems' data matching over time. When a student transfers schools and their record updates in three places, that's sync working (or not working).
  • Data element / Field — A single piece of information, like "date of birth" or "grade level." Integration problems are often really field-mapping problems: your SIS calls something "Grade," the other system calls it "GradeLevel," and someone has to tell the two systems these mean the same thing.
  • Vendor / Third-party system — Any outside company's software your district connects to your core systems (SIS, HR, finance). When people say "the vendor," they mean whoever built and supports that outside tool.

Identity & Authentication

  • SSO (Single Sign-On) — Logging in once (usually with your district Google or Microsoft account) and getting access to multiple tools without re-entering a password each time. This is the outcome districts want; SAML and OAuth below are two different technical ways to deliver it.
  • SAML 2.0 — An older, still widely used standard for SSO, common with education identity providers (like a district's Google Workspace or Active Directory setup talking to a vendor's product). When a vendor's setup guide mentions "SAML metadata" or "NameID format," they're asking your IT team to configure how your identity system introduces a user to theirs.
  • OAuth 2.0 / OpenID Connect (OIDC) — A newer standard that does two related things: OAuth controls what an app is allowed to do on your behalf (e.g., "read this student's grades" but not "edit them"), and OIDC layers identity on top so the app also knows who is logging in. Most modern "Sign in with Google/Microsoft" buttons use this. If a vendor asks for a "client ID and secret," this is the standard they're using.
  • Token — A temporary digital credential, like a wristband at an event, proving a user or system has already been checked in and is allowed access — without needing to re-enter a password every time. Tokens expire, which is why a connection that worked yesterday can suddenly stop working today (the token wasn't refreshed).
  • Identity Provider (IdP) — The system that verifies who someone is — usually your district's Google Workspace, Microsoft Entra ID (formerly Azure AD), or a platform like Clever or ClassLink. Vendors integrate with your IdP; they don't replace it.
  • Clever / ClassLink — Two popular K-12-specific platforms that sit between your SIS and dozens of classroom tools, handling both rostering (sending class lists) and SSO (handling logins) so your district doesn't have to build a separate connection to every vendor individually. Many districts use one of these as their central rostering "hub."
  • MFA (Multi-Factor Authentication) — Requiring a second proof of identity beyond a password (a text code, an authenticator app). Increasingly required by vendors and cyber-insurance policies, and worth knowing as a term even if IT owns the implementation.

Data Standards You'll Hear About

Why standards exist: Without them, every vendor would describe a "student" or a "course section" differently, and every new integration would require custom translation work from scratch. Standards are shared blueprints so systems can plug into each other more predictably.

  • Ed-Fi — A comprehensive, education-specific data standard (and open-source technical toolkit) originally built with input from state education agencies. It defines, in detail, what a "student," "school," "course," or "assessment result" looks like as data, so a state or district can exchange information with many vendors using one common structure. You'll hear about specific versions (v3.x, v5.x) because the standard has evolved and not all vendors support the newest version yet.
  • OneRoster — A simpler, narrower standard focused specifically on rostering and grade data (who's enrolled in what class, and passing grades back to the SIS). It's widely supported by classroom tools and LMS platforms because it's more lightweight than Ed-Fi. Comes in two flavors: a CSV file version (simpler, batch-based) and a REST API version (real-time).
  • CEDS (Common Education Data Standards) — A national data dictionary — not a live technical system like Ed-Fi or OneRoster, but a reference that defines terms consistently (e.g., exactly what counts as "chronic absenteeism") so states, districts, and researchers mean the same thing when comparing data.
  • 1EdTech (formerly IMS Global) — The standards organization behind several K-12/higher-ed interoperability specs, most notably LTI (covered below), along with Common Cartridge (packaging course content), QTI (packaging assessment questions), and Caliper (tracking learning activity data). When a vendor says a product is "1EdTech certified," it means they've passed conformance testing for one of these specs.
Why this matters practically: You don't need to memorize field-level specs. You need to recognize these names when a vendor mentions them, and know that "we support OneRoster" is a meaningfully different (and usually easier) claim than "we support Ed-Fi."

How Data Actually Moves

  • Batch — Data sent in a scheduled bundle rather than instantly — for example, a file of all roster changes generated once overnight. Simple and reliable, but not immediate: a same-day transfer might not show up in the other system until the next morning's batch runs.
  • Real-time / Streaming — Data sent the moment it changes, rather than waiting for a scheduled batch. More technically demanding to build and maintain, but means a schedule change reflects everywhere within seconds or minutes instead of overnight.
  • Webhook — A way for one system to notify another the instant something happens, instead of the second system having to repeatedly ask "anything new yet?" Think of it as a doorbell instead of knocking every five minutes to check if someone's home. Often used for things like "notify our grading system the moment an assignment score changes."
  • Full refresh — Re-sending the entire dataset every time (every student, every enrollment), rather than just what changed. Simple to reason about, but slow and resource-heavy for large districts.
  • Incremental sync — Sending only what changed since the last update, rather than everything. Faster and more efficient, but requires both systems to reliably track "what's changed" — which is where sync bugs tend to live.
  • Roster drift — When two systems that are supposed to match slowly fall out of sync — a student shows as enrolled in one system but withdrawn in another. Usually caused by a sync failure that went unnoticed. This is one of the most common real-world integration headaches districts deal with.
  • Idempotency — A technical property meaning "running this same update twice causes no harm." Worth knowing because if a vendor's system isn't idempotent, retrying a failed transfer can accidentally create duplicate records (two copies of the same student, doubled attendance entries) — a real, recurring source of data-quality problems.
Why this matters practically: When something isn't showing up where you expect it, "is this a batch or real-time connection, and when did it last run?" is often the fastest diagnostic question you can ask a vendor's support team.

Learning Tool Interoperability (LTI)

  • LTI (Learning Tools Interoperability) — The standard that lets a teacher click a link inside your LMS (Canvas, Schoology, Google Classroom) and land inside a third-party tool — already logged in, with the right class roster — without a separate login. This is why a teacher can click "Quiz" inside their LMS and land directly in a testing tool with their class already loaded.
  • Platform vs. Tool — In LTI's own language, the "Platform" is your LMS (it hosts the class), and the "Tool" is the outside app being launched into it (a quiz maker, a video library). Vendors use this exact language in their documentation, so knowing which side is which helps you read their setup guides correctly.
  • LTI 1.3 / LTI Advantage — The current, more secure version of the standard (replacing the older LTI 1.1). "LTI Advantage" refers to a set of add-on capabilities built on top of 1.3 — described below.
  • Deep Linking — Lets a teacher browse a tool's content from inside the LMS and pick exactly what to assign (a specific video, a specific quiz) rather than just linking to the tool's homepage.
  • Grade Passback (Assignment and Grade Services / AGS) — Lets a score entered in the third-party tool flow automatically back into the LMS gradebook, so teachers aren't manually re-entering grades from two systems.
  • NRPS (Names and Roles Provisioning Service) — Lets the third-party tool pull the accurate, current class roster directly from the LMS at launch time, instead of needing a separate roster file.
Why this matters practically: If a teacher reports "the grade didn't come back" or "my roster is wrong in this tool," you now know these are AGS and NRPS problems specifically — useful vocabulary when escalating a support ticket to a vendor.

Security & Compliance Terms

  • Encryption in transit / at rest — "In transit" means data is protected while moving between systems (like a sealed envelope crossing town); "at rest" means it's protected while sitting in a database (like a locked filing cabinet). A vendor should be able to confirm both, clearly, without hedging.
  • Least privilege — The principle that a person, app, or system should only be able to access the minimum data it actually needs to do its job — not everything available. If a vendor's app is requesting far more access than its function requires (a hall-pass app asking for full grade access, say), that's worth questioning.
  • FERPA (Family Educational Rights and Privacy Act) — The federal law governing student education record privacy. In integration conversations, "FERPA-aligned" usually refers to specific technical practices (access controls, audit logs, data minimization) that support the law's requirements — not a certification a vendor can simply purchase.
  • COPPA (Children's Online Privacy Protection Act) — The federal law governing data collection from children under 13 online. Relevant when evaluating any tool students under 13 will use directly.
  • Data minimization — Only collecting and sharing the specific fields actually required for a tool to function, rather than sending a vendor a student's entire record when they only need, say, a name and a grade level.
  • Audit logging — A system's record of who accessed or changed what data, and when. When something goes wrong (a grade changed unexpectedly, a record disappeared), this is the log your team needs to be able to pull to find out why.
  • Retention policy — Rules for how long data is kept, and when/how it's deleted — both within your own systems and by any vendor holding your students' data. Worth asking any vendor directly: "What happens to our data if we stop using your product?"
Why this matters practically: You're rarely expected to implement these controls yourself — but you're very often the person a vendor's sales team is trying to reassure, and knowing these terms lets you ask a follow-up question instead of taking "we're secure" at face value.

Decoding Vendor-Speak

A quick-reference for common lines from vendor sales calls, onboarding forms, and security questionnaires — what they're really asking, and a good follow-up question.

Vendor says What they mean Ask this
"We support OneRoster" They can accept a standard roster file or feed — usually the easier integration path "CSV or REST? Full refresh or incremental sync?"
"We're Ed-Fi certified" They've passed conformance testing for the more comprehensive Ed-Fi standard "Which Ed-Fi version, and which domains (attendance, assessment, etc.)?"
"We integrate with Clever/ClassLink" They can receive rosters and/or handle SSO through that hub, instead of a custom connection "Rostering, SSO, or both? Instant Login or sync-based?"
"We need your SAML metadata" Your IT team must configure your identity provider to trust their application Route directly to IT/network staff — this is a technical setup step, not a policy decision
"We're FERPA compliant" A general claim, not a certification — there's no official FERPA certification body "Can you walk me through your data retention and deletion process specifically?"
"We need API access with these scopes" They're requesting specific, limited permissions (least privilege) to specific data types "Why do you need this scope, and what breaks if we don't grant it?"
"Our integration is real-time" Data should reflect changes within seconds to minutes, not overnight "What happens if a sync fails silently — how would we know?"
"We can do a full data export" They'll hand back everything — check the format and whether it's genuinely usable elsewhere "In what format, and can we get a sample before we commit?"

Have a phrase that regularly leaves your team confused? Send it to SDLA and we'll add it here.