Selling EdTech into UK, Australian, Canadian and US Schools: An Integration Guide

TL;DR

If you build learning software for schools or universities in the UK, Australia, Canada or the US, the product is only half of what buyers evaluate. The other half is how cleanly it plugs into the systems they already run: the student information system (SIS) or management information system (MIS), the learning management system (LMS), and the identity provider. The standards you will meet are LTI 1.3 and LTI Advantage for launching tools inside an LMS, OneRoster 1.2 for rosters and grades, and, depending on the market, Ed-Fi (US states), SIF (Australia) or a rostering broker such as Wonde (UK and Australia). On top of that sits a privacy expectation that Canadian regulators spelled out in October 2025 and that every region increasingly shares. This guide explains what each piece does, how they differ by region, and how to sequence the engineering so you do not build four integrations when one well-chosen core would do.

Why integration decides EdTech deals

Ask a school IT lead why a promising tool never got past the pilot and the answer is rarely "the pedagogy was weak". It is usually "we could not get our class lists into it", "teachers had to log in twice", or "grades did not flow back". Each of those is an interoperability failure, and each lands on a small IT team that has to maintain the workaround.

Procurement has caught up with this. The 1EdTech consortium, which maintains LTI and OneRoster, publishes suggested RFP language that asks institutions to require 1EdTech conformance certification, to ask vendors which LTI Advantage services they support and are certified for, and to check a current certification registration number at imscert.org. The same page tells institutions that student and faculty interaction data belongs to them and that vendors should provide a copy on request in a format the institution specifies.

So integration is not plumbing you add after launch. It is part of the sales collateral, the security questionnaire and the contract. If you are still shaping the product itself, our overview of LMS platform development covers the wider architecture; this article stays on the connective tissue.

The four jobs integration has to do

It helps to separate four jobs, because different standards handle different ones.

1. Rostering. Who are the students, teachers and classes this term, and who is enrolled in what?
2. Launching. How does a teacher open your tool from inside the LMS without a second login?
3. Grade and outcome return. How do scores and completion data get back to the gradebook?
4. Identity and provisioning. How are accounts created, updated and removed as people join and leave?

A common beginner mistake is to treat these as one problem and buy or build a single "integration". They are separate, they change at different speeds, and the standards for them are separate too.

LTI 1.3 and LTI Advantage: launching and grade return

Learning Tools Interoperability (LTI) is the 1EdTech standard that lets a platform, usually an LMS, integrate external tools in a standard way. Version 1.3 and LTI Advantage added a new model for secure message and service authentication built on OAuth 2.0 and OpenID Connect.

Three details matter when you plan the build:

• Security is not optional. A tool requests an access token by asserting its identity with a signed JWT. The 1EdTech guide says platforms and tools must support RSA256 signatures with keys of at least 2048 bits, that platforms must expose their public keys through a JWKS endpoint, and that implementations must reject tokens whose issuer or audience values do not match.
• Three services sit on top of the core launch. Assignment and Grade Services (for sending scores and line items back), Names and Role Provisioning Services (the tool asks the platform for the course roster) and Deep Linking (letting a teacher pick specific content from your tool and place it in a course).
• Anonymous launches are legal. The guide states it is not an error to launch fully anonymously, which matters in regions where minimising student identifiers is a selling point.

Certification is a separate process, and the guide notes that only 1EdTech members can apply. You can build a compliant integration without certification, but expect larger buyers to ask for it in the RFP. Budget the time, and the membership decision, early.

One practical point: the LTI guide includes a side-by-side comparison of LTI 1.1 Basic Launch and LTI 1.3 messages and points to a migration guide. If you are still shipping a 1.1 integration, plan the move rather than waiting for a customer to force it.

OneRoster 1.2: rosters and grades

LTI can pull a roster for a single course, but it does not replace a school-wide sync from the SIS. That is OneRoster's job. The OneRoster 1.2 implementation guide describes it as a way of securely sharing class rosters and related data between an SIS and any other system. Version 1.2 has three services, each with its own REST binding: Rostering, Gradebook and Resources.

Two bindings exist:

• CSV. A zip of between one and 14 CSV files, one per entity type, UTF-8 encoded, with a manifest.csv. The files must be semantically complete, so a classes.csv needs the academic sessions, courses and organisations it refers to.
• REST/JSON. System-to-system exchange using OAuth 2.0 bearer tokens with the client credentials grant. It supports sorting, filtering, field selection and pagination.

The core entities are users, organisations, academic sessions, courses, classes and enrolments. In 1.2 a user can hold multiple roles, each tied to an organisation, which models a teacher who also coordinates a department, or an adult learner who also tutors.

For a tool vendor, the design question is whether you consume OneRoster, provide it, or both. A learning app usually consumes. A platform that holds the system of record, such as an admissions or student records product, usually provides. If you are building the latter, see our notes on admissions CRM work, where the same enrolment data originates.

Region by region: what you will meet in practice

The standards above are global. The way schools actually receive data is not. Here is how the four target markets differ, based on what the relevant bodies publish.

United States: Ed-Fi, OneRoster and the state layer

State education agencies often hold student data in an Ed-Fi-based data store, and districts commonly use rostering services to feed learning tools. In May 2026, 1EdTech published that Ed-Fi ODS/API 7.3.2 includes a native OneRoster API, combining the Ed-Fi Data Standard with OneRoster 1.2 for students, teachers, classes and enrolments. The post names Tennessee and Delaware Departments of Education as participants. Its stated aim is one standards-based rostering connection instead of custom integrations and spreadsheets, and its suggested step for providers is simply to support OneRoster 1.2 to reduce custom builds.

The takeaway for a vendor: OneRoster 1.2 is the safest single rostering investment for the US, because the state-level infrastructure is moving towards exposing it directly. Procurement language will also reference FERPA; our article on EdTech data privacy under FERPA, GDPR and the DPDP Act goes deeper on that side.

United Kingdom: MIS integration through a broker

UK schools run MIS products such as SIMS, Arbor, Bromcom and iSAMS. Rather than integrating with each one, many suppliers connect through a broker. Wonde describes itself as a platform sitting between the MIS and apps. Its schools page says it is used by over 30,000 schools and integrated with more than 700 applications, lists MIS providers including Arbor, Bromcom, SIMS, iSAMS and PowerSchool, and states alignment with UK GDPR and the Data Protection Act 2018. Its schools offer includes a "Control" area for monitoring permissions and managing compliance such as DPIAs.

That page does not set out the supplier-side technical details, so confirm access terms, data scopes and any fees directly with the broker before you commit. The planning point is architectural: if you expect to sell to UK schools, design your ingestion layer so that the source can be a broker API, a OneRoster feed or a CSV, and put the school's approved data scope in configuration rather than code.

Australia: SIF and Australian school systems

Australia has its own interoperability specification. The SIF Association publishes the Systems Interoperability Framework, and its Australian implementation specification, version 3.4.8, dated 18 March 2021, describes itself as a technical blueprint rather than a product. The Australian data model is XML-based, with objects grouped under headings such as attendance, finance, learning standards, NAPLAN, timetabling and wellbeing, and StudentPersonal sits in the student baseline profile. The infrastructure document defines a secure REST-based transport, and JSON is supported through mapping rules.

Wonde's own partner page also describes tools that sync data to approved third-party apps for schools in Victoria's and Western Australia's government education departments, which shows that state-level systems matter. Check which state or sector you are targeting before assuming a single national route; the sources we reviewed do not describe one.

Canada: privacy first, then integration

Canadian buyers tend to open with privacy. In October 2025 the federal, provincial and territorial privacy regulators adopted a joint resolution on educational technologies. For vendors, it says to design with the child's best interests in mind, use privacy by design and data minimisation, default to the most protective settings, test security throughout the lifecycle, and explain clearly what is collected, why, where it is stored and who it is shared with. It also says not to use student data for marketing, product improvement or AI training without specific consent, and recommends publishing Privacy Impact Assessments, plus Algorithmic Impact Assessments for AI systems.

The regulators also looked at the PowerSchool breach. In November 2025 the Ontario and Alberta commissioners reported that some or all of the school bodies lacked certain contract provisions and oversight, including monitoring of remote support access and multi-factor authentication, and had not limited remote access to as-needed. The recommendations were aimed at school bodies and governments, not vendors, but the practical effect is obvious: your Canadian customers will push those controls down into your contract and your security questionnaire.

Plan for Canadian deals with LTI 1.3 and OneRoster for the technical link, and for a privacy package (PIA-ready documentation, minimal data scopes, access logging, support-access controls) as a first-class deliverable.

Regional comparison

Treat this as a planning map, not a guarantee. Individual districts, trusts, boards and universities override the pattern constantly.

A build sequence that avoids rework

Teams tend to go wrong by integrating to the first customer's system, then redoing it for the second. A more durable order:

1. Define your internal model first. Persons, roles, organisations, terms, classes and enrolments, mirroring OneRoster's entities. Everything else maps to and from this. If you already run a multi-tenant product, the lessons in our piece on scaling a multi-tenant EdTech platform apply to keeping tenant data scopes clean.
2. Build the ingestion layer as adapters. One adapter each for OneRoster CSV, OneRoster REST, and a generic CSV mapper. Add broker or SIF adapters when a real deal demands them.
3. Implement LTI 1.3 launch, then the services you need. Start with the launch and Deep Linking, add Assignment and Grade Services when teachers ask for grade return, and add roster pull if you do not already have a OneRoster feed.
4. Add provisioning and deprovisioning. Leavers matter as much as joiners. Test what happens when a student moves class mid-term.
5. Write the data-scope matrix. For each integration, list every field you receive, why you need it and how long you keep it. This one document answers most security questionnaires, and it is the backbone of a PIA.
6. Pursue certification when pipeline justifies it. Start with LTI Advantage; consider OneRoster after.

The API development and integration work behind this is mostly unglamorous: retries, idempotent syncs, clear error reports for school IT teams. That is also what separates tools that survive their first term from those that do not.

Assessment, video and other special cases

Some product types add their own constraints. Proctored or high-stakes assessment tools often need tighter identity binding and audit trails; see our notes on assessment and proctoring platforms. Video-heavy learning products have infrastructure concerns that interact with school networks and device limits; our article on video-based learning at scale covers that. Neither changes the integration core described above, but both raise the bar on logging and data-handling documentation.

Common mistakes

• Treating LTI as a rostering solution. It launches tools and can pull course rosters; a school-wide sync still needs a OneRoster-style feed or a broker.
• Over-collecting. Requesting every field "just in case" slows security reviews and conflicts with the data-minimisation expectations Canadian regulators set out. Ask for what the feature needs.
• Hard-coding a customer's quirks. Put mappings in configuration. The next customer's system will differ.
• Ignoring support access. The PowerSchool findings centred partly on remote support access and multi-factor authentication. Decide how your own support staff reach customer data and document it.
• Skipping deprovisioning. Orphaned student accounts become a compliance problem long after the integration "works".
• Assuming one UK, Australian or Canadian route. Sector and state differences are real. Ask early.

Conclusion

The EdTech vendors that clear procurement fastest are the ones who treat interoperability and privacy as product features. Model your data around OneRoster's entities, launch through LTI 1.3, keep regional adapters thin and configurable, and write down exactly what data you take and why. That gets you most of the way to the UK, Australian, Canadian and US markets without a rewrite per country.

If you are planning that architecture, or untangling an integration that has grown organically, we are happy to talk it through. Book a meeting, and the booking page will show times in your own time zone.

References

• 1EdTech. LTI Implementation Guide. https://standards.1edtech.org/lti/specifications/guides/implementation_guide/implementation-guide
• 1EdTech. Suggested LTI Advantage requirements for RFPs. https://www.1edtech.org/standards/lti/suggested-lti-advantage-requirements-rfps
• 1EdTech. OneRoster 1.2 Implementation Guide. https://standards.1edtech.org/oneroster/guides/standards/v1p2/impl
• 1EdTech. Aligning the ecosystem: a common path forward for student data (May 2026). https://www.1edtech.org/blog/aligning-the-ecosystem-a-common-path-forward-for-student-data
• Wonde. Schools. https://www.wonde.com/schools/ and partner MIS/SIS page https://www.wonde.com/partner-mis-sis/
• SIF Association. SIF Implementation Specification (Australia) 3.4.8. https://files.a4l.org/Implementation/AU/3.4.8/ImplementationSpecification.pdf
• Office of the Privacy Commissioner of Canada. Joint resolution on educational technologies, 8 October 2025. https://www.priv.gc.ca/en/about-the-opc/what-we-do/provincial-and-territorial-collaboration/joint-resolutions-with-provinces-and-territories/res20251008edtech/
• Office of the Information and Privacy Commissioner of Alberta. PowerSchool breach findings, 18 November 2025. https://oipc.ab.ca/ontario-and-alberta-privacy-commissioners-release-investigation-findings-into-powerschool-breach-affecting-school-boards-and-other-educational-bodies/