Strategy · Aula · 2026 · v1.0
How Vera reaches Aula's data — the three routes, a phased strategy to get officially enrolled through a municipal sponsor, and what the plumbing actually looks like.
The gate
There is no consumer door into Aula.
Every sanctioned route into Aula requires one thing: an institution — a school or municipality — that signs you in as its data processor. That's the whole game. A competitor like SkoleElev.ai has an official two-way Aula integration precisely because its customer is the school; the school signs the data agreement. Vera's customer is the parent — and a parent cannot authorize institutional data access, because they aren't the data controller.
KOMBIT-approved third-party UI embedded inside Aula. KOMBIT controls test-env access and approves every widget before production. The lowest official bar.
UNI-Login SSO + institutional rosters, via two signed agreements: provider↔STIL, and provider↔school. This is the "institutional API."
The two-way Beskeder/Kalender sync a full integration has. Not public — negotiated through KOMBIT/Netcompany. The most gated piece.
Getting "enrolled with Aula" as a consumer app is impossible directly. The strategy is to manufacture a municipal sponsor and walk the official doors behind it — while shipping today on a route that needs no permission.
The three routes
All three deliver the full cross-app parent app. Holding official Aula access does not block the other connectors — Holdsport, Famly, Digital Post, the calendar each run on their own access model. So the real trade isn't capability; it's reach, cost and control.
| Route | Solves the problem (UX) | Survives a shock (risk) | The catch |
|---|---|---|---|
| A — School-side official | ✓✓ full app, at customer schools | ✓✓ sanctioned, unkillable Aula leg | reach gated to schools you've sold; B2G cost & time; two-hats legal |
| B — Partner sub-processor | ✓ full app, if a partner says yes | ~ partner is a single point of failure | not in your control; margin + rival leverage |
| C — Own-account current plan | ✓✓ full vision, any parent, now | ✗ kill-switch = #1 company risk | grey-zone, revocable, sole child-data controller |
A and C aren't different companies. A is the hardening path for C's Aula connector — school by school. The parent app is identical; only how the Aula leg is fed changes. Best reach today = C. Best risk posture = A. Keep the connector swappable and you don't have to choose.
Enrollment strategy
Ship the parent app on the own-account connector. The point isn't only revenue — it's ammunition: parent users, willingness-to-pay data, and a school-pain narrative ("parents are drowning in Aula; here's proof they'll pay to fix it"). That narrative is what opens a municipality.
Target a friendly municipality's school/digitalisation office. Sell the pain they feel — skole-hjem-samarbejde, less parent overload — not "another learning platform" (that lane is taken). A pilot intent gives you standing to apply. Then open both official doors in parallel and clear the compliance gate.
KOMBIT widget → bm@kombit.dkSTIL tilslutning + dataaftaleDPA · DPIA · security auditReference-sell to more kommuner (new agreement, same tech). Negotiate the deep two-way message/calendar mirror with KOMBIT/Netcompany — a live reference is your leverage. Run a partner pipe (Route B) in parallel for reach at non-customer schools.
If the KOMBIT/STIL timeline (quarters) is too slow, a partner sub-processor deal gets sanctioned data faster — a good bridge, a bad foundation. Or ship a widget-only footprint first (no data access): a digest inside Aula that deep-links to the app.
Technical map
The app never talks to Aula directly. It talks to an internal connector interface — a normalized model of messages, events, tasks and roster. Behind it, the Aula adapter is swappable. That's what turns the Phase-0→Phase-1 migration into a backend change, not a rebuild.
{messages · events · tasks · roster} → [ aula-ownaccount · aula-widget+stil · aula-partner ] → AulagetAulaToken() bridge hands your backend a short-lived token, exchanged via a KOMBIT-issued shared secret over mTLS to resolve guardian ↔ child ↔ institution.selected-aktoer=KONTAKT), held by session cookies + Csrfp-Token + profile_change=2.www.aula.dk/api/v18/ — profiles.getProfileContext, messaging.getThreads, posts.getAllPosts, calendar.createSimpleEvent (the one-tap add).Under A, Aula/STIL data reaches you as the school's processor for the school's purpose. Powering a parent's personal assistant is a different purpose with a different controller — the parent, via consent. You run both hats explicitly, and the data agreement has to permit the hand-off. This is the real seam, not a technical blocker. Route C sidesteps it (parent is sole controller) but carries the grey-zone access risk.
Own-account to win parents now. Keep the Aula connector swappable so a partner pipe — or official school-side access — can harden it later.
Recommendation · ship C, keep B warm, A only on a B2G move
Confidence: the own-account surface is verified from reverse-engineered sources; the official widget / STIL mechanics and the deep message mirror are inferred from KOMBIT & STIL documentation plus SkoleElev's public claims — the exact contracts sit behind KOMBIT's NDA'd test environment. Confirm specifics with KOMBIT once a municipal sponsor is in place. Early-stage internal strategy; figures and mechanics are directional desk research.