Most Indian schools that run both an administrative system and a learning platform run two of everything: two logins, two web addresses, two rosters that drift apart by the third week of term, and two support numbers when something breaks.
EdunodeX ships its own learning platform, LMX, and the integration work is mostly about making sure the school never experiences it as a second system.
A learning platform on the school’s own domain
LMX carries what a learning platform is expected to carry: courses, chapters, activities, assignments, and learner progress against them.
It runs as a separate service that EdunodeX operates, and teachers and learners reach it under a path on their own school’s domain rather than at a different address. That choice removes a set of problems that are boring and expensive in practice — a second origin to explain to parents, a second certificate to renew, a second bookmark that a substitute teacher does not have.
Inside EdunodeX, all contact with the platform goes through a single bridge module, which is the only thing that talks to the learning platform’s administrative interface. Nothing else in the application does. That gives one place where authorisation, error handling and the data boundary are enforced, and it is why the integration can be switched off cleanly.
The bridge is also deliberately pluggable. Each school record names which learning platform it uses, and one of the valid values disables the integration outright.
Opt-in per school, off by default
The gate on this integration is a data-protection gate, not a licensing gate, and it is written to fail closed.
Two conditions must both hold before any synchronisation, sign-in or assignment path does anything: the school must have the learning platform explicitly enabled, and it must have a provider configured. Both, not either. That distinction is not academic — the provider field carries a default value for every school, so treating the two as alternatives would have opened the gate for every school on the platform, including the ones that never opted in.
With the gate closed, every path is a no-op and no personal data crosses the boundary at all.
A platform administrator turns it on for a school from tenant management, which flips the flag and writes an audit record. Provisioning is lazy: the school’s space on the learning platform is created on first use, not when the toggle is flicked.
Commercial plans start with this off. The exception is the government schools package, where the board-lesson classroom is the whole product and the school has no other teaching surface — there the consent posture is handled upstream, at programme level, rather than by a per-school switch.
When roster synchronisation does run, it sends an allow-listed minimum: name, a synthetic email address, and role. Not addresses, not guardians, not fee status, not attendance.
One organisation per school
Each school gets its own organisation inside the learning platform, identified by a stable, opaque slug derived from the school’s internal identifier.
That identifier choice is worth explaining because it looks like a detail and is not. It is deliberately not the school’s name, which is editable, and not its subdomain, which can be repointed. A school that rebrands or moves subdomains does not orphan its courses.
The resolved organisation is stored against the school record, so the common path is a local lookup rather than repeated network calls on every sign-in.
Most importantly, the school a request belongs to is always resolved from EdunodeX’s own link records, never from an identifier returned by the learning platform. Trusting the external system to say which school a record belongs to would make the tenant boundary depend on something outside EdunodeX’s control.
Courses, classes and the shared catalogue
The mapping between EdunodeX’s academic structure and the learning platform’s is explicit. A school becomes a group; a class becomes a user group. Because the platform has no native nesting, the hierarchy is maintained as an EdunodeX-owned naming and identifier convention rather than pretended into existence.
A teacher provisions their class, then assigns a course to that class for a specific subject. That assignment is keyed on the class and the subject together, so Class 7 Science and Class 7 Mathematics are distinct assignments rather than one bundle.
Content follows the same fork-and-extend pattern EdunodeX uses elsewhere. A school can fork a catalogue course to customise it, and its classes then resolve to the fork while every other school continues to read the catalogue copy. Assigning a catalogue course deep-copies it into the school’s own organisation, so “shared catalogue” precisely means that each school receives its own copy, with EdunodeX remaining the source.
All of the links — school to group, class to user group, class and subject to course — live in EdunodeX’s own tables.
Board lessons rendered for learners
Board lessons authored in Lesson Studio are imported into the learning platform as one activity per slide, with the slide’s own structured content carried across.
The platform renders those slides itself, in the learner’s language, with their images and audio. This is a second, independent implementation of the same slide contract that the school’s classroom player reads — the learning platform covers the full range of slide types, and the classroom player covers a subset.
Two behaviours are built for the failure cases rather than the happy path. A slide type the renderer does not recognise shows a visible unsupported notice rather than a blank page. A missing asset degrades to its text label rather than to a broken image.
The boundary here runs one way and only one way. Lesson Studio and the classroom player remain EdunodeX-owned; the learning platform consumes that catalogue and never authors into it.
Progress and grades flow back as read-only facts
The learning platform reports back over signed webhooks — course and activity completions, assignment grades — to a receiver that verifies the signature before accepting anything.
Events are reverse-mapped back to the right student and the right class and subject, and recorded as learner progress facts. Teachers see them in a recent activity panel alongside the class’s courses.
They are not written into the gradebook, and that is a decision rather than an unfinished feature. Report card marks in EdunodeX are teacher-entered or teacher-confirmed records with a named author. A completion event from a learning platform is external, unreviewed data. Letting it flow silently into an assessment record would break the property that every mark in a report card is one a person put there. If a school wants those results to count, that is a reviewed step, separate from the passback.
Signing in without a second password
A teacher moving from EdunodeX into the learning platform is issued a short-lived hand-off token and lands already signed in. There is no second password to set, forget, or reset.
Hand-off is scoped to teaching and administrative roles, and it is a different thing entirely from the long-lived server-to-server credential the bridge uses, which is never placed in a web address.
One characteristic of the sign-in path is worth knowing if you build against it: minting a hand-off token also re-synchronises the user’s role on the learning platform side. A mint call that omits the role does not leave the role unchanged — it demotes the user. Every caller passes it explicitly.
The teacher’s daily entry point is a courses page that shows today’s timetable periods, read from EdunodeX’s own timetable. Each period whose class and subject has a linked course offers a direct action that mints a fresh token and opens that course. The learning platform has no concept of a scheduled course, so nothing about scheduling is pushed into it — the timetable stays single-sourced in EdunodeX, and the platform is only ever deep-linked into.