How Omniscol works — one API, one source of truth

A few things about how Omniscol is built are worth knowing before you integrate with it — they explain why the API is so complete, how the interface adapts to each user, and one privacy point to keep in mind.

One application over one API

Omniscol runs as a single web application in your browser. Every screen, button and table is drawn by calling Omniscol's own public API — the same API you can call yourself, documented on Omniscol's interactive API reference, the Developers page (omniscol.com/en/developers). There is no hidden, "real" API behind the one you integrate with: what the interface uses is what you get. A few operations go the other way — offered for integration but not used by the application itself: for example, the advanced search and entity-resolution endpoints (meant for an AI agent through MCP), or the endpoints that let an external system feed data into Omniscol (an ETL keeping an external database in step).

operationId — one key, one source of truth

Every operation is a method + URL (for example GET /api/schedules/lessons/{datesrange}), and each one carries a stable identifier: its operationId (here os_schedules_dates_get). The name is structured: os (Omniscol), then the module (schedules), then what the operation acts on (dates — sometimes several dash-joined parts), and always the HTTP method last (get, post, put, delete). That one key is what Omniscol uses everywhere — to name the operation on the Developers page, to build the matching MCP tool, and to point at it from an override or from this help. Defined once, it keeps every surface in sync: the documentation, the tools and the interface can never drift apart, because they all read the same definition.

The interface follows your rights

A graphical element with an action — a button, a tab, a menu item — appears only when the operation behind it is available to you. That depends on your role and your custom roles (see Users and roles), and on your plan and options (see Omniscol plans and options). Change any of those and the interface re-composes itself: elements, and whole modules, appear or disappear accordingly.

The same principle applies beyond your personal rights. The IT department can disable certain operations through an API override, and the matching elements disappear from the interface (see API tweaks). The same holds when a piece of data is kept up to date by an external synchronization: its local create and edit operations can be disabled, and their controls then give way to the synchronization (see Synchronization with external systems).

This is why Omniscol has no separate portal for students or teachers. There is one application; each person sees the interface synchronized to their own rights — a student, a teacher, an administrator and a holder of a custom role each get exactly the operations they are entitled to, and nothing else.

The interface is a convenience, not the lock

Because the interface is driven by your rights, it is tempting to think of a hidden button as a security boundary. It is not. Every call is re-checked on the server against your identity and your rights; an operation you are not entitled to is refused there, whatever the interface happens to show. The interface adapts for clarity and comfort; the actual boundary is enforced server-side, on each request.

Tokens and share links, same model

An API token or a share link is scoped to a set of operations — the ones you authorize when you create it. The server enforces that scope on every call, exactly as it does for a signed-in user. A share link, a token and a person in the interface are three ways to reach the same rights-checked API — never a side door around it.

Working through a connection drop

Because every screen reads the API, Omniscol can also keep the responses it has already received in your browser, so that a brief network loss does not interrupt your reading. This local copy lives in its database (IndexedDB), alongside the browser's ordinary page cache. This is a read cache: if the connection drops, you keep seeing what you had already opened. It does not queue or replay your edits — a change still goes to the server.

This local copy rests on your consent. The first time on a browser, Omniscol asks whether you trust it; the copy begins once you agree. The Offline cache entry in the user menu turns it on or clears it at any time afterward — a check marks when it is active.

Two things worth knowing:

• Personal data is left out. Only successful reads are kept; responses the server marks as non-storable (session and authentication data) are never cached, and from what is cached the software strips the details it keeps about people — email, phone, date of birth, login, ID number, password status — and removes administrator accounts entirely. The local copy holds ordinary working data, not the personal directory.
• On a shared computer, prefer a private / incognito window. Signing out does not erase this local copy (nor the browser's normal cache); a private window discards both when it closes. This is the same care any web application deserves on a machine you don't control.