Development ·
One engine for our UI, SDK and MCP
Our developer platform plan starts with shared permissions and useful service operations, so integrations cannot bypass the rules that protect learners.
A booking widget, an academy dashboard and an authorised assistant may look very different. They should still agree on who can read a register, change a session or see a learner’s private work. We are planning the developer surface around that shared authority.
Start with the service operation
We want one set of operations for course discovery, availability, bookings, enrolment and progress. Each checks the tenant, actor, permission, resource and enabled features. Our own interface, the public API and later adapters should call those operations rather than recreate their own rules.
An SDK should remove repetition
Our planned TypeScript and JavaScript SDK will provide typed requests, useful errors, pagination, timeouts and explicit retry behaviour. A retry must not turn one booking into two. We will generate what we can from an approved API contract and test examples against working sandbox routes before publishing a package.
MCP needs narrow, useful tools
Our MCP plan starts with capability discovery and scoped reads, then carefully controlled actions. An assistant might inspect session availability or prepare a booking change. A consequential action needs a reviewable payload and the right authority; text inside a course description cannot grant it.
We will not expose an unrestricted shell, SQL console or a shortcut to private learner records. A customer-owned assistant should receive only the tools and fields its operator is entitled to use.
Keep release claims honest
The public versioned API, SDK and MCP server described here are planned, not released developer products. Existing personal account endpoints do not prove that every proposed operation exists. We will publish supported versions and runnable examples as the service operations are implemented.
Our next step is the shared service, audit and contract foundation, followed by an additive course/session model. That gives later integrations a dependable place to connect without making them a second application.