Strict-Reference Modeling

Strict-reference folders let you model dependent data—catalogs with SKU variants, product lines with configuration bundles, regions with offices—without stitching together custom routers or cleanup jobs. Mark a folder (and its descendants) as strict_reference, and FoxNose enforces ownership, builds hierarchical URLs, and cascades operations automatically.

How Strict-Reference Works

Schema-level flag – Set strict_reference to true when creating or updating a folder via the dashboard or the Folders API. Only non-root folders can enable it, and children must inherit the same setting.
Ownership enforcement – Every resource in a strict folder stores the parent’s UID. Creating a child without a parent ID is rejected, and deleting the parent cascades to all descendants.
Automatic routing – When you connect the deepest folder to a Flux API, FoxNose automatically inserts the strict ancestors into the URL with allowed_methods: [], so consumers get RESTful paths without exposing extra data.

This behavior is handled at the platform level—no custom triggers, DB scripts, or router edits required.

Example: Courses, Modules, Lessons

📁 Courses (Collection, alias: courses, strict_reference: false)
└── 📁 Modules (Collection, alias: modules, strict_reference: true)
    └── 📁 Lessons (Collection, alias: lessons, strict_reference: true)

Data integrity – A lesson cannot exist without a module, and a module cannot exist without a course. The Management API enforces this via strict-reference checks, ensuring that content relationships are always valid.
Delivery URL – Connect only the Lessons folder to a Flux API. FoxNose automatically exposes routes such as:

/api_prefix/courses/:course_key/modules/:module_key/lessons/
/api_prefix/courses/:course_key/modules/:module_key/lessons/:lesson_key/

Cascade deletion – Removing a Course (or Module) via the Management API automatically removes all its dependent children (modules, lessons); Flux immediately stops routing to those paths, preventing orphaned data.

Editing Strict Chains

Adding fields or components – Schema versions behave the same as any folder. Publish new versions via Versions and Fields; FoxNose reuses the existing ownership metadata.
Moving folders – You cannot move a strict folder outside its chain. Update requests that change the parent to a non-strict folder return strict_reference_inheritance_mismatch.
Content operations – Creating, updating, or deleting resources follows the standard Resources API.

Flux API Behavior

When a strict chain is connected to Flux:

List/Search – Calls such as GET /api_prefix/projects/{project}/milestones/{milestone}/tasks or POST .../tasks/_search are permitted only if get_many is enabled on the leaf folder. The router validates each ancestor in the strict chain before executing the query.
Get One – GET .../tasks/{task} is available when get_one is enabled. The router ensures the task belongs to the given milestone + project and returns route_not_found if any part is invalid.
URL-only segments – Ancestor folders automatically appear with allowed_methods: []. They provide the path segments but cannot be queried directly unless you explicitly connect them to the API and grant permissions.

Reference: Build Flux APIs for a primer on automatic folder inclusion.

Best Practices

Use strict-reference for compositional data – Comments inside posts, SKUs inside catalogs, configuration bundles that only make sense under a parent.
Keep aliases meaningful and plural – Since aliases become URL segments, choose stable names (projects, milestones, tasks) to avoid frequent rebuilds.
Test with staging folders – Create the hierarchy in a non-production environment, populate sample data via the dashboard or import scripts, then connect to a preview Flux API to validate the routing.