Admin content tree
Admin routes are scoped to a team and hub:Member content
Members read content through hub routes:Publishing and visibility
There is no separate “publish” verb for a content node — a node becomes member-visible when both are true:published_atis set at or before now. A node withpublished_atunset (draft) or in the future (scheduled) is hidden fromGET /api/v1/hub/{hub_id}/content. Set it withmio content create … --published-at <RFC3339>ormio content update <id> --published-at <RFC3339>.privacypermits the viewer —public,members, orpaid(mio content create … --privacy members).
mio content create --node-type lesson --privacy public --published-at "$(date -u +%Y-%m-%dT%H:%M:%SZ)" yields an immediately member-visible node.
Content nodes vs. media playlists
A hub has two independent member-content surfaces, and it’s easy to conflate them:- Content nodes (this guide) —
GET /api/v1/hub/{hub_id}/content, managed withmio content …. - Media playlists — the
hub_mediasurface atGET /api/v1/hub/{hub_id}/playlists, published withmio media hub-playlists publish(see the media workflow guide), notmio content.
/content, etc.) built in the page builder renders whichever data source its content grid is bound to. A grid bound to dataSource: { "type": "hub_playlists" } shows only media playlists — that’s why mio content create nodes don’t appear on a playlist-bound page even when published. To surface content nodes on a page, bind that page’s grid to the content-node source; to fill a playlist-bound page, publish media playlists.