Written by Technical Team | Last updated 20.08.2026 | 24 minute read
For many EdTech companies, integration starts as a customer request rather than an architectural strategy.
A school asks whether the product can connect to its management information system. A university wants student records synchronised from its SIS. Another customer wants single sign-on. A large prospect cannot proceed unless the product works with its learning management system. The engineering team assesses the requirement, reads the relevant API documentation, builds the connector and gets the customer live.
At first, this is entirely reasonable.
If an EdTech company has only a handful of customers requiring integrations, building them individually can be faster and cheaper than creating an elaborate integration framework before there is evidence that one is needed. Engineering teams should be wary of premature abstraction. There is little value in designing a sophisticated platform capable of supporting fifty connectors when the business currently needs two.
The problem begins when the temporary approach quietly becomes the permanent architecture.
One integration becomes three. Three become eight. The company expands from schools into multi-academy trusts, or from individual institutions into larger university groups. Customers use different MIS, SIS, LMS, identity and assessment platforms. Some systems expose modern REST APIs; others rely on scheduled files, vendor middleware, webhooks, proprietary data models or combinations of several approaches. Each customer has slightly different expectations about what should synchronise, how frequently it should happen and which system should be authoritative.
Eventually, the organisation discovers that it does not really have eight integrations. It has eight miniature software products embedded inside its main product.
Each connector has its own authentication behaviour, mappings, schedules, error handling, configuration, deployment assumptions and support procedures. Knowledge becomes concentrated in individual engineers. A small change to the application’s core data model unexpectedly affects several connectors. API limits imposed by one supplier cause customer-specific failures. A new academic year exposes assumptions nobody documented. Support teams cannot tell whether a failed synchronisation is caused by the EdTech platform, a customer’s configuration, an upstream MIS or an individual record that cannot be mapped.
At this stage, integration is no longer simply a feature.
It has become an architectural domain in its own right.
The important question for an EdTech company is therefore not whether integrations should be centralised from day one. It is knowing when the accumulated cost and complexity of one-off connections have become greater than the cost of creating an integration platform.
That transition is one of the more important architectural decisions a growing EdTech company can make.
The first few integrations often look deceptively similar.
An EdTech platform needs pupils, students or staff. It authenticates against another system, retrieves records, converts them into its internal format and stores them. Perhaps it runs overnight. Perhaps users trigger it manually. Perhaps a scheduled job performs the work every hour.
The obvious implementation is to place the logic directly inside the main application.
A SyncStudentsFromSystemA service is created. Later, ImportClassesFromSystemB appears. A third connector has its own scheduled worker. Another uses a webhook endpoint. Each solves a genuine business requirement.
For a while, this is productive engineering.
The difficulty is that every external education system introduces variation in several dimensions simultaneously.
Consider something apparently straightforward such as a class roster.
One MIS may identify a pupil with a permanent internal identifier. Another may expose separate person and enrolment identifiers. A university SIS may model the relationship through programmes, modules, course offerings and teaching groups. One platform may return deleted records. Another may simply stop returning them. One may expose changes immediately while another produces a nightly extract. Staff roles may be strings in one system, numeric codes in another and institution-configurable values in a third.
Even standardised interfaces do not remove all of this complexity.
OneRoster can create a common structure for exchanging users, organisations, courses, classes, enrolments and grades. LTI can standardise how learning tools are launched from learning environments and support related workflows. Edu-API is designed around standardised academic enterprise data exchange in higher education. SCIM can provide a common approach to provisioning identities.
These standards are valuable precisely because they reduce unnecessary variation. They do not, however, make every institution identical.
An institution may implement only part of a standard. An upstream product may offer optional fields that another omits. Customers may interpret organisational structures differently. Data quality varies. Local configuration varies. Academic calendars vary. Institutions disagree about what constitutes an active user. Products frequently need information that sits outside the scope of a particular standard.
The integration therefore needs two distinct forms of knowledge: knowledge about the external system and knowledge about the EdTech product’s own domain.
When these are mixed together inside individual connectors, complexity compounds.
Imagine that the internal product represents every learner using a single Student object. Five connectors independently contain logic for constructing that object. The product team later introduces a distinction between a learner’s core identity and their institution-specific enrolment.
If the integration architecture has no shared transformation layer, five connectors may need to change independently.
At twenty connectors, this becomes twenty changes.
At fifty, integration work can begin to dominate the roadmap.
This is one of the most important signs that a company is approaching an architectural threshold: the cost of adding integrations starts growing with the number of integrations already built.
In a scalable architecture, the opposite should gradually become true. The organisation should learn from every connector it builds. Authentication components, mapping rules, synchronisation infrastructure, monitoring, tenancy controls and operational tooling should increasingly be reused. The twentieth connector should benefit from fifteen architectural decisions made while building the first nineteen.
If it does not, the business is accumulating integration debt.
Integration debt behaves much like other forms of technical debt, except that its external dependencies make it particularly expensive. A company controls its own codebase. It does not control when an MIS supplier changes an endpoint, when an LMS retires an authentication mechanism or when an institution restructures its data.
Every bespoke connector expands the number of places where external change can enter the product.
This is why counting connectors alone is a poor measure of integration maturity. Two companies might each advertise twenty integrations. One has twenty independently built code paths maintained by engineers who understand particular vendors. The other has twenty adapters attached to a common integration platform with standard monitoring, mapping, credentials, tenancy, scheduling and failure management.
From a sales perspective, both appear to support twenty systems.
From an engineering and operational perspective, they are completely different businesses.
The point at which an EdTech company needs to rethink its architecture is therefore not determined by a magic number. Some businesses may encounter the problem at six connectors; others may operate comfortably with fifteen.
The more useful question is whether integration variability has begun leaking into the core product.
When every new connector requires new scheduling logic, new database structures, new administration screens, new support procedures and changes to application services, the architecture is signalling that integration needs its own boundary.
The architectural transition usually becomes necessary before somebody formally proposes an “integration platform”.
The evidence appears elsewhere first.
Engineering estimates increase. Integration incidents become harder to diagnose. Sales asks why seemingly similar connectors take radically different amounts of time. Customer success teams become dependent on developers to investigate synchronisation problems. Deployments become risky because nobody is sure which customers use which integration behaviours.
Most importantly, integrations begin consuming product capacity even when no new integration is being built.
This is the integration tax.
A useful way to recognise it is to examine whether the organisation is experiencing several of the following symptoms:
Any one of these problems can be fixed locally. When several occur together, local fixes usually make the architecture worse.
The temptation is to create a shared library.
This is often a good first step. Shared authentication clients, retry logic, logging conventions and data types can remove obvious duplication. However, an integration platform is more than a utilities package.
A library standardises code. A platform standardises behaviour.
That distinction matters.
Consider retry logic. A shared retry library may ensure every connector backs off when an upstream API returns a temporary error. Useful, but incomplete.
A platform asks larger questions.
What is the retry policy for each integration operation? Which errors are transient? At what point should processing stop? Can the operation safely be attempted again without creating duplicate data? Where does a permanently failed item go? Who is alerted? Can an operator inspect and replay it? Does the customer’s administration interface show that its data is stale?
Those are not implementation details. They are operational capabilities.
The same is true of authentication.
A code library may know how to obtain OAuth tokens. An integration platform needs to know which institution owns the credentials, when they expire, how secrets are rotated, which scopes have been granted, whether the connection is healthy and which workflows depend on it.
At scale, the integration platform becomes the place where the EdTech company manages its relationship with external systems.
That is a much larger responsibility.
There is also a commercial warning sign that is easy to overlook: the integration catalogue starts influencing which customers the company can win.
A young EdTech business may treat integrations as supporting features. Later, prospective customers often place them near the beginning of procurement conversations.
“Do you integrate with our MIS?”
“Can you provision users from our identity provider?”
“Does it work with our VLE?”
“Can grades be returned automatically?”
“Can we roll it out across forty schools without configuring every school manually?”
When those questions begin determining whether deals move forward, integration capability has become part of the product’s market position.
At that point, treating every connector as an engineering project creates a mismatch between how the market values integrations and how the organisation produces them.
The commercial team effectively sells integrations as product capabilities while engineering delivers them as bespoke projects.
A platform architecture closes that gap.
The phrase “integration platform” can create the wrong mental image.
It does not necessarily mean introducing a large enterprise service bus, purchasing an iPaaS product or splitting the application into dozens of microservices.
The objective is much simpler: create a stable architectural layer between the EdTech product and the changing world of external education systems.
A strong design separates four concerns that are often tangled together in one-off connectors.
The first is vendor connectivity.
The platform needs adapters that understand the mechanics of each external system: authentication, endpoint structure, pagination, rate limits, webhooks, file formats, vendor-specific identifiers and API peculiarities.
An Arbor adapter should understand Arbor. A Banner adapter should understand Banner. An LTI component should understand LTI. A OneRoster connector should understand the relevant OneRoster exchange.
Those components should not need deep knowledge of how the EdTech application’s own database happens to represent every object.
The second concern is translation.
External data needs to be converted into a consistent internal representation.
This is where a canonical or domain model becomes useful, although it must be designed carefully. Creating a gigantic “universal education data model” that attempts to represent everything supported by every MIS and SIS is usually a mistake. Such models become abstract, difficult to understand and increasingly full of optional fields.
The better approach is to model what the EdTech product actually needs.
If the product needs people, organisations, academic groups and memberships, define those concepts explicitly. Let each connector translate the external system into those concepts. Preserve relevant source identifiers and metadata where necessary, but prevent vendor-specific data structures from spreading through the rest of the application.
This boundary is strategically important.
Suppose five MIS platforms describe teaching groups differently. Without an integration layer, the product may gradually develop five different interpretations of a group. With a common model, each adapter answers the same question: “How should this upstream concept be represented in our product?”
That makes differences explicit rather than accidental.
The third concern is orchestration.
An integration is rarely a single request.
A roster sync may need to obtain organisations first, then users, then classes and finally enrolments. It may need to process thousands of records. Some operations can run concurrently; others depend on previous results. An upstream service may impose rate limits. A customer’s connection may disappear halfway through processing.
A scalable integration platform therefore needs to manage work, not merely make API requests.
This is where asynchronous processing often becomes valuable.
Instead of keeping a long-running request alive while a complete institution synchronises, the platform can create a synchronisation job, divide it into manageable tasks and process those tasks through queues or workers. Large customers no longer monopolise application resources. Temporary upstream failures can be retried deliberately. Poison messages or persistently invalid records can be isolated rather than blocking an entire synchronisation.
Idempotency becomes essential.
If an enrolment update is processed twice because a worker restarts or a message is delivered again, the result should still be one correct enrolment rather than two conflicting records. Integration systems must assume that networks fail in awkward places. A request may succeed upstream while its response never reaches the caller. A job may be interrupted after writing data but before recording success.
Designing operations so they can safely be repeated is one of the less visible differences between an integration that works in testing and one that survives years of production use.
The fourth concern is the control plane.
This is the area many internally built integration layers neglect.
The data plane moves pupils, students, staff, courses, classes, grades or other information. The control plane determines how integrations themselves are managed.
For each customer, the organisation should eventually be able to answer questions such as:
Which connectors are enabled?
When did each connector last run successfully?
Which credentials and permissions does it use?
What data is synchronised?
Which direction does that data travel?
How frequently does synchronisation occur?
What is the current health of the connection?
How many records were created, changed, ignored or rejected?
What was the last failure?
Can the failed operation be retried safely?
Which internal or external version is the connector running against?
This operational layer is what turns integration from hidden infrastructure into a manageable capability.
It also enables a critical change in responsibility.
Customer success and implementation teams should not need an engineer every time a school reconnects its MIS or a university wants to inspect its synchronisation status. Mature integration architecture creates safe operational tooling around common support actions.
That does not mean exposing every technical control to customers. It means designing the system so ordinary operational work does not require direct database access and engineering intervention.
One of the hardest integration architecture problems in education is balancing standardisation with reality.
EdTech companies naturally want every institution to use exactly the same connector in exactly the same way. Institutions naturally assume their workflows, policies and data structures are perfectly reasonable.
Both positions contain some truth.
The architectural mistake is to solve the tension through customer-specific code.
Suppose an application synchronises users from an MIS. One school wants pupils in Years 7 to 11. Another wants Sixth Form included. A MAT wants all pupils except those in a particular status. An international school uses year labels that do not match the assumptions in the original implementation.
The quickest response is conditional logic inside the connector.
That approach works once.
After twenty customers, the connector becomes an undocumented rules engine.
A platform architecture should instead make legitimate variation configurable while refusing arbitrary variation that damages the product.
Configuration might determine which organisations are in scope, which group types should synchronise, whether inactive records are retained, what frequency should be used or whether a supported optional workflow is enabled.
The important point is that configuration remains structured.
It should have a known schema, validation, defaults and versioning. It should be observable. Two customers with different settings should still be running the same connector.
This is especially important in multi-tenant EdTech products.
Every integration operation should carry tenant context from beginning to end. Authentication credentials, imported records, logs, messages, metrics and errors must remain associated with the correct institution. A processing spike from one large university or MAT should not silently degrade synchronisation for every other customer.
Tenant-aware observability becomes increasingly important as the platform grows.
A metric that says “97% of synchronisations succeeded” is useful but insufficient.
Which 3% failed?
Was one institution responsible for all failures?
Was one vendor responsible?
Were all failures caused by authentication expiry?
Did ten customers receive incomplete class data because an upstream endpoint changed?
Is one unusually large tenant causing queue latency?
Without dimensions such as tenant, connector, operation and job, integration monitoring produces impressive dashboards with limited diagnostic value.
The same discipline should apply to logging and tracing.
A single synchronisation may move through an API endpoint, scheduler, queue, transformation service and database worker. If each component logs independently without a shared correlation identifier, an engineer investigating a failed pupil record is forced to reconstruct the sequence manually.
Correlation should be built in.
Every job should have an identity. Individual operations should be traceable. The platform should be able to reconstruct what happened to a particular upstream entity without exposing unnecessary personal data in logs.
Education introduces an additional complication: lifecycle events matter as much as initial provisioning.
Many early integrations are designed around creation.
Create the school. Create the users. Create the classes.
Production systems spend far more time handling change.
A pupil moves class.
A student’s module enrolment changes.
A member of staff leaves.
A course is renamed.
Two duplicate records are merged upstream.
An academic year ends.
A student returns after suspension.
A school restructures its groups.
An institution changes SIS.
The architecture therefore needs a deliberate model for reconciliation.
A synchronisation should not simply ask, “What does the upstream system contain?” It must ask, “What has changed, what does that change mean and what should happen to the state we already hold?”
Deletion is a classic example.
If an external API stops returning a student, does that mean the student has been deleted, has left the institution, is outside the configured scope, is temporarily unavailable because the upstream API is incomplete, or was excluded because a request failed halfway through?
Treating absence as deletion can be dangerous.
A mature platform therefore distinguishes full snapshots from incremental updates, understands source semantics and uses cautious reconciliation policies.
Academic rollover deserves similar attention.
At the start of a new school or university year, unusually large amounts of data may change in a short period. New classes appear. Existing memberships end. New pupils or students arrive. Staff responsibilities change. Timetables may remain unstable for days or weeks.
An integration architecture designed around ordinary daily change can fail under rollover load even though the same system performs perfectly for the rest of the year.
This is where queue-based processing, rate-limit awareness, resumable synchronisation and checkpointing provide practical value. A job processing 80,000 enrolments should not need to restart from zero because record 63,421 triggered an unexpected error.
Nor should one malformed record prevent 79,999 valid records from reaching the product.
Good integration platforms isolate failure.
They distinguish between failures of the entire connection and failures affecting individual data. They make partial outcomes visible. They allow engineers or operators to correct and replay failed items where appropriate.
They also acknowledge that not every workflow needs to be real-time.
“Real-time integration” is frequently treated as inherently superior, but education systems contain many use cases where predictable eventual consistency is safer and more economical.
A student’s single sign-on experience may require immediate behaviour. A nightly synchronisation of infrequently changing curriculum metadata may be perfectly adequate. A timetable update might justify event-driven handling if the source supports reliable events, while a full reconciliation still runs periodically to detect missed changes.
Architecture should be driven by the operational requirement, not fashion.
Recognising that one-off integrations have reached their limit does not mean stopping product development for a year and replacing the entire integration estate.
That is usually the wrong response.
The most successful transition is incremental.
Start by identifying what is genuinely common across existing integrations.
Not what architects hope will be common in theory, but what the production code demonstrates repeatedly.
Look for repeated patterns around credentials, tenant configuration, connection health, scheduling, API consumption, pagination, mapping, synchronisation jobs, error classification, logging, audit history and support tooling.
Those repeated patterns become candidates for platform capabilities.
A sensible migration often starts with the control plane because it creates value without requiring every connector to be rewritten immediately.
Introduce a consistent model for customer integration connections. Store which system each institution uses, its configuration, credential references, connection state and supported capabilities. Standardise how integrations are enabled and disabled.
Next, standardise execution.
Create a common job model. Give every synchronisation a job identifier, timestamps, status, metrics and structured outcome. Make existing connectors report through it even if their internal implementation remains different.
Then improve observability.
The organisation should be able to answer three questions rapidly:
What should have happened?
What actually happened?
Why are those two things different?
Those questions sound simple. Many integration estates cannot answer them without an engineer reading raw logs.
Once execution and visibility are consistent, shared transformation boundaries can be introduced. New connectors should use the common domain model first. Existing connectors can migrate when they require significant changes rather than being rewritten purely for architectural neatness.
This is an important principle.
Do not replace working integrations merely because their code is unattractive.
Architecture exists to reduce business risk and increase delivery capability, not to maximise conceptual purity.
The transition can be thought of as moving through four stages.
Not every EdTech company needs to reach the fourth stage.
A specialist product serving a narrow market with three stable external systems may be better served by a modest framework. Architecture should reflect the business model.
However, an EdTech company pursuing broad institutional adoption should consider the strategic consequences of remaining at stages one or two.
If every major customer requires integration, the ability to produce, configure and operate integrations becomes a scaling constraint on the whole company.
The sales organisation cannot scale faster than engineering can deliver connectors.
Customer onboarding cannot scale faster than engineers can diagnose configuration problems.
Support cannot scale if every synchronisation failure becomes a development ticket.
International expansion cannot scale if assumptions about UK school structures are embedded throughout the integration code.
Product acquisitions become harder if every acquired product has a separate way of connecting to the same institutional systems.
This is why the integration platform should eventually be viewed as internal product infrastructure.
It has users.
Developers use its connector interfaces and development tooling.
Implementation teams use its configuration capabilities.
Support teams use its operational views.
Customers benefit from its reliability and may interact with portions of its administration experience.
Product managers depend on its capability model.
Sales teams depend on the integration catalogue it enables.
Treating it as a product changes how it is governed.
Connectors should have ownership, versions, tests, documentation and lifecycle policies. Upstream API changes need to be monitored deliberately. Deprecation should be planned. Integration incidents should generate learning that improves the platform rather than producing another customer-specific patch.
A connector catalogue also creates an opportunity to separate supported capability from assumed capability.
“Integrates with System X” is often too vague to be useful.
Does the connector provision users?
Does it synchronise classes?
Does it support guardians?
Does it write grades back?
Does it support incremental synchronisation?
Does it receive events?
Which versions of the upstream product are supported?
Which fields are required?
What permissions must the institution grant?
A mature integration platform can describe those capabilities explicitly.
This improves sales conversations because the organisation can make precise commitments rather than discovering limitations during implementation.
It improves engineering because capability becomes machine-readable rather than hidden in documentation.
It improves customer experience because expectations are established before onboarding begins.
Eventually, this architecture can change the economics of integration development.
The first connector to a new category of system may still be expensive. The company must understand the domain, establish authentication patterns, model unfamiliar data and solve operational edge cases.
The second should be easier.
The fifth should be significantly easier.
Not because third-party APIs have become simpler, but because the company is no longer rebuilding everything around the API.
It already has tenant management.
It already has synchronisation jobs.
It already has rate-limit handling.
It already has retry infrastructure.
It already has dead-letter processing.
It already has observability.
It already has reconciliation rules.
It already has a domain model.
It already has operational tooling.
The new work is concentrated where it belongs: understanding what is unique about the new external system.
That is the architectural payoff.
The goal of an integration platform is not to eliminate integration complexity. Education technology is too diverse for that. Schools, colleges and universities use different systems because they have different requirements, histories and operating models.
The goal is to contain complexity.
Vendor-specific complexity should live inside adapters.
Customer-specific variation should live in controlled configuration.
Product meaning should live in a coherent domain model.
Long-running work should live in resilient orchestration.
Failures should live somewhere operators can see and resolve them.
Security and tenant boundaries should apply consistently.
Monitoring should tell the organisation whether education data is actually flowing, not simply whether servers are running.
Once those boundaries exist, integration stops being a collection of exceptions and becomes an organisational capability.
That transition matters because interoperability increasingly determines whether an EdTech product can fit into the institutional environment around it.
A strong product that cannot connect to existing systems creates administrative work. A product that requires every school to maintain duplicate users and class lists becomes difficult to operate. A university platform that cannot exchange data cleanly with its SIS, LMS or identity environment may struggle to progress through technical evaluation regardless of the quality of its core functionality.
As EdTech companies grow, they therefore face an architectural question that is also a commercial one.
Are integrations projects you build when customers ask for them?
Or are they part of the platform you sell?
For an early-stage company, the first answer may be exactly right.
For a growing company serving increasingly complex institutions, it eventually becomes expensive.
The moment to change architecture is not when the integration estate finally collapses under its own weight. It is when the evidence shows that individual connectors are no longer independent features: when they are repeating the same infrastructure, competing for the same engineering capacity, generating the same operational problems and becoming central to winning and retaining customers.
That is the point where further one-off development stops buying speed and starts borrowing it from the future.
An integration platform repays that debt by creating a repeatable way to connect.
And for an EdTech company that intends to operate across dozens of systems, hundreds of institutions and millions of changing education records, repeatability is what turns interoperability from a technical burden into a scalable product capability.
Is your team looking for help with EdTech interoperability and integration? Click the button below.
Get in touch