Most signage platforms publish a list of integrations. We build to whatever you already run, which is why the list has no natural end.
That model exists because each connector is hand-built and has to earn its place against every other customer request. If what you run is on the list, good. If it is not, you are waiting for a roadmap.
If a system has an API, a feed, an export, a database we can read, or a page that publishes the information, it can reach a screen. The question we ask is not whether you are on a supported list. It is what your data comes out of, and what it looks like.
This is not a new ambition. The same team spent years connecting phone systems and customer platforms to whatever a business already had: electronic medical records, home medical equipment and patient management systems, ordering and billing platforms, and in one case a day trading firm. Dozens of systems, none of which were on anybody's list.
An API of any shape, modern or otherwise.
A feed or export on a schedule, however it is published.
A page you already publish that carries the information a screen needs.
A directory for sign-in, so staff use the accounts they already have.
These arrive on their own. None of them were a product feature we happened to have; each is a connection built to what that school already had.
The school already publishes its menus on its own website. We read them from there, and breakfast and lunch appear on the screens for the right day without anyone retyping anything.
Term dates, holidays, early releases and events flow in from what the school and its district already publish, and the screens follow them.
Odd and even days, and the days that break the pattern, are what the building actually runs on. The screens know which day it is because the calendar does.
Staff sign in with the district accounts they already have. No new password, no separate directory, and access ends when their district account does.
Coursework, assignments and due dates are read from the learning management system the district already runs, so what a class is actually working on is known to the platform rather than described to it.
Events do not have to be re-entered in one more system. Where a school keeps its calendar is where we read it from.
The point is not the menu. It is that a school secretary is not maintaining a slideshow, because the information already existed somewhere and now it reaches the wall by itself.
In a signage product, an integration ends at a template: data goes in, a slide comes out, and that is all it will ever be. Here the information lands where Ava can reason about it, so the same connection that puts lunch on a hallway screen can answer a parent asking what is being served, or tell a teacher whether Monday is a school day.
That is why the list has no natural end. Each connection makes the platform know more about how your organisation actually runs, rather than adding one more thing to display.
We are the people who write it. A connection to a system you already run does not have to survive three layers of prioritisation before someone starts.
An integration built for you is not contingent on a partnership, a revenue share, or the other vendor staying interested.
Student information system, point of sale, flight or queue data, building management, a directory, a spreadsheet somebody maintains, or a page you already publish. Describe it and we will tell you honestly what it takes and how long.