Getting a connector built

Twenty-six connectors ship in the box. If the system you run is not one of them, it can be added.

This page is for deciding what to ask for. It is the one page here aimed past an administrator, and it stays deliberately short.

First, check you need one

Two things worth ruling out before anyone writes code.

Is there an equivalent already? Features depend on a job to be done, not on a supplier. If you need device lookups and your MDM is not listed, any of the five device management connectors gives the repairs screen everything it needs. The question is not “is my vendor listed” but “is the job I need already covered”.

Does the system have an API at all? Some school systems do not, or gate it behind a licence tier. That is worth confirming before scoping anything, because it decides whether this is a fortnight or impossible.

What a connector is

A single file that declares five things:


Which category it belongs to	Device management, student information, email, and so on
How it authenticates	A token, a username and password, OAuth, a directory bind
What settings it needs	The fields you fill in on the connector screen
Which secrets it needs	Encrypted before storage, never shown again
Which jobs it can do	From the capability list

Plus a test-connection check, so Save and test can tell you whether it works, and one function per job.

Connectors never touch the database. They return data and the platform decides what to keep, which is what stops a badly behaved one corrupting anything.

What building one involves

For a system with a reasonable API, a connector is a small piece of work, usually a few days including tests. The parts that take the time are rarely the code:

Getting API access from the supplier, which can take weeks in education software.
Working out what their data actually means, which is where most of the effort goes. Two student information systems will both give you a year level and disagree about what it counts.
Deciding what to do when a field is missing. A connector that guesses is worse than one that returns nothing, because somebody will make a decision on the guess.

What to ask for

If you want one built, the useful things to have ready:

Which system, and which edition or tier you are on.
A link to its API documentation, if it is public.
What you want it to do, in terms of the jobs above. “Look up a device by serial and tell me who it is assigned to” is scopeable. “Integrate with our MDM” is not.
Whether it is reachable from the internet or lives on your network. The second needs a connector agent on managed hosting.
Who can get you credentials, and how long that usually takes.

Priority connector development is part of the Enterprise tier. Outside that, a connector other schools would also use is worth raising regardless, because anything that ships gets maintained, tested and documented alongside the rest.

Building it yourself

The connector contract is a documented, versioned interface, and the source of every shipped connector is in the product repository. If you have a developer who wants to write one, start by copying the connector closest to what you need. The catalogue covers enough shapes (token, OAuth, service account, directory bind, private network) that something will be close.

Two rules matter more than the rest:

Return the shape your category expects. Every device connector returns the same fields, which is exactly what lets a school swap suppliers without touching the repairs screen. Match the connector next to yours.

Add a demo mode. A few lines, and it is how people evaluate, demonstrate and train before real credentials exist. Every shipped connector has one for that reason.

Contributing it back is worth doing. Once it ships, somebody else keeps it working when the supplier changes their API.