When a school agrees to pilot an AI tool, the first conversation is usually about the product itself. Does it do what we need? How much does it cost? What does the onboarding look like? The conversation that tends to go poorly, or not happen at all until it is too late, is the technical one: how does your tool actually connect to our systems, and what does that require from our IT staff?
The K-12 LMS landscape is dominated by Canvas and Google Classroom, with a significant tail of schools using Schoology, Brightspace, and a handful of older or regional platforms. Each of these has a different integration story -- different authentication mechanisms, different data models, different roster sync behavior, and different data export options. An edtech tool that says "we integrate with Canvas and Google Classroom" could mean anything from a deep, real-time bi-directional integration to a manual CSV export that the teacher runs once a week.
Roster sync is where most pilots first hit trouble
The most common early integration problem is roster data: getting accurate, up-to-date lists of which students are in which class, with stable identifiers that persist across the school year. This sounds trivial but is frequently not.
In Canvas, roster data is available through the Canvas Data API, but accessing it requires an API key provisioned by the district's Canvas administrator. Most districts have policies about which vendors can request API access, and the approval process can take weeks. During a pilot, this means that a school that agreed to start in the first week of October might not have functional roster sync until early November, by which point pilot momentum has often been lost.
Google Classroom uses a different approach: applications access class data through the Google Workspace APIs, which require that the district's Google Workspace administrator grant domain-wide access to the application. This is also a non-trivial step that requires IT involvement, and it sits on a different approval track than the Canvas API request. If a school uses Google Classroom but the IT approval for Google Workspace API access takes three weeks, the pilot is delayed regardless of how quickly other onboarding steps are completed.
There is also a mid-year roster change problem. Students transfer in and out of classes. New students enroll. Teachers sometimes restructure their rosters for non-academic reasons. An integration that does a one-time roster pull at the start of the pilot will go out of sync over time. An integration that requires manual roster updates will work only as well as the teacher or administrator remembers to run them. A well-designed integration should handle roster changes automatically, which requires either a periodic sync or a webhook that fires when roster changes occur in the LMS.
Gradebook and activity data exports are inconsistently structured
After roster sync, the next integration challenge is getting student activity data back into the LMS in a form that teachers can use. Many teachers want to see AI-generated diagnostic results alongside their existing gradebook, not in a separate tool they have to log into separately. This requires writing grades or activity records back to the LMS -- and this is where the differences between platforms become significant.
Canvas has a relatively well-documented Gradebook API that allows external tools to post grades and comments to existing assignments. But it requires creating the assignment in Canvas first, which means either the teacher creates the assignment in Canvas and links it to the external tool, or the external tool creates the assignment automatically. The automatic creation approach requires careful handling to avoid cluttering the teacher's Canvas gradebook with unwanted assignments.
Google Classroom's approach to external grade submission is more restrictive. The Classroom API allows reading class and student data but is limited in what external tools can write back. Tools that want to show data in a teacher's Google Classroom view often end up working around this by generating Google Forms that feed into a Google Sheet rather than writing directly to the Classroom gradebook. This works, but it requires more setup steps and produces a more fragmented teacher experience.
Single sign-on reduces friction but adds complexity
Single sign-on (SSO) is highly desirable in school contexts because students and teachers should not have to create separate accounts for every tool. Both Canvas and Google Workspace support OAuth-based SSO, and for Google Classroom schools, "Sign in with Google" is often the path of least resistance for students who already have Google accounts from their district.
But SSO introduces its own complications. Google's OAuth implementation for school-aged users includes additional restrictions under the Student Data Privacy Consortium and Google's education policies that differ from consumer OAuth. Districts may need to explicitly whitelist an application in their Google Workspace admin console before students can use "Sign in with Google." This step is often missed in pilot planning discussions, resulting in a situation where teachers can sign in but students cannot.
Canvas SSO through LTI (Learning Tools Interoperability) is technically robust but requires configuration on both sides: the Canvas administrator adds the external tool as an LTI provider, and the tool receives a launch token that includes the user's Canvas identity. This is a more reliable integration pattern for school contexts than OAuth in some ways, but it requires the Canvas administrator to be involved in setup, which again means IT tickets and approval timelines.
What this means for pilot planning
The practical implication for schools and edtech vendors planning a pilot is that the IT integration timeline needs to be accounted for in the project plan, not treated as a background task that will sort itself out. A realistic checklist includes: identifying the LMS in use and confirming API access policies, submitting API key or OAuth approval requests at least three weeks before the planned pilot start, confirming that SSO will work for both teacher and student accounts, and establishing who is responsible for handling mid-year roster updates.
For vendors, this means being specific and honest in sales conversations about what the integration actually requires. "We integrate with Canvas and Google Classroom" should be accompanied by a one-page document that outlines the IT steps required and the expected timeline for each. Pilots that fail due to integration delays often leave a negative impression of the product that has nothing to do with the product's actual quality -- and a little upfront clarity avoids a lot of downstream frustration.