Skip to main content
A Space is a community container — a named area where users can post entities, discuss in threads, and interact under configurable membership and permission rules. Spaces support hierarchical nesting, customizable read/post permissions, and avatar and banner images. The API returns three space shapes depending on context:
  • Space — the standard shape, returned when fetching a list of spaces.
  • SpaceDetailed — returned when fetching a single space by ID, shortId, or slug. A superset of Space with added permission and hierarchy context.
  • SpacePreview — a minimal snapshot, never returned as a standalone response. Only appears embedded inside SpaceDetailed as the shape of parentSpace and each item in childSpaces[].

​
Space

​
SpaceDetailed

Returned when fetching a single space by ID, shortId, or slug. Includes all Space fields plus the following:

​
SpacePreview

A minimal space shape used only as an embedded reference — never returned directly by any endpoint. Appears as SpaceDetailed.parentSpace (the space one level up) and inside SpaceDetailed.childSpaces[] (spaces one level down).

​
SpaceMemberPermissions

Included in SpaceDetailed.memberPermissions for authenticated users who are members.

​
Visibility

visibility is a distinct axis from readingPermission. Visibility governs whether the space object is listed and discoverable; reading permission governs who can read the content inside it. The two are fully independent — you can have a public space that only members can read, or an unlisted space that anyone can read once they have the link.
unlisted is not access control. It only affects discoverability — it does not restrict who can read the content inside the space. To gate content, use readingPermission.
Visibility can be set on create and update, and changes take effect immediately and are freely reversible in both directions. A member of a space always continues to see it in surfaces that list their own spaces (e.g. memberOf=true, user spaces, mutual spaces) regardless of its visibility.

​
NSFW flagging

NSFW is a separate axis from both visibility and moderationStatus — flagging a space (or entity) NSFW labels it, it does not hide or remove it. Every space carries its own nsfw boolean plus a denormalized nsfwEffective:
  • nsfw — the space’s own flag, defaulting to false. Toggled by space admins (via create/update) or by project admins from the dashboard.
  • nsfwEffective — the denormalized rollup:
    It is maintained on write: creating a space under an NSFW parent inherits nsfwEffective = true even if its own nsfw is false, and toggling a space’s own nsfw recomputes nsfwEffective top-down across its entire descendant subtree in the same transaction. A root space’s nsfwEffective equals its own nsfw.
Because nsfwEffective folds in the whole ancestor chain, it is what an entity’s live nsfwEffective reads from — flagging a space instantly cascades to every entity within it and its sub-spaces. See Entity → NSFW flagging. To filter a list by effective NSFW, pass nsfwFilter to Fetch many spaces (include-all default / exclude / only).
The space nsfwFilter keys off each space’s own nsfwEffective, so only can return an NSFW child whose safe parent is omitted — results are not guaranteed to form a contiguous tree. Consumers building a tree from the result should not assume completeness.
Sublay only labels and filters NSFW content. It does not blur, age-gate, add interstitials, or store a per-viewer “show mature content” preference — presentation is the consuming app’s responsibility.