Permissions
Permissions control what your app can access on the Teachfloor platform.
Overview
Permissions control three types of access:
- Contextual Data: Data the platform includes in event callbacks (course, module, element)
- Storage & Features: Platform features your app can use (data storage, AI generation)
- Public API: Endpoints your app's servers can call via OAuth (
api.teachfloor.com/v0/*) — see OAuth for the full mapping.
All permissions must be declared in your app manifest with a user-facing explanation.
How Permissions Work
Permissions are enforced on two surfaces:
- SDK — when your app subscribes to events, the platform includes an
objectContextparameter containing contextual data based on your granted permissions. For example, withcourses:readpermission,objectContext.courseincludes the current course data when in a course viewport. - Public API — when your app opts into OAuth, a subset of permissions is minted into the access token as OAuth scopes, unlocking the matching endpoints on
api.teachfloor.com/v0/*. See OAuth for details.
Some permissions apply to both surfaces (e.g. courses:read grants SDK context AND GET /v0/courses/*); others are surface-specific (e.g. members:read is API-only, appdata:read is SDK-only).
See Integration Guide - Events for detailed objectContext structure and usage examples.
Available Permissions
Your app can request the following permissions:
Contextual Data Permissions
| Permission | Description | Access Type |
|---|---|---|
user:read | Access user profile information | User data in objectContext |
user_events:read | Access user activity events | User events |
courses:read | Access course contextual data | Course object in objectContext |
modules:read | Access module contextual data | Module object in objectContext |
elements:read | Access element contextual data | Element object in objectContext |
Storage Permissions
| Permission | Description | Access Type | Hierarchy |
|---|---|---|---|
appdata:read | Read organization-wide app data | Storage API - App Data | Read only |
appdata:write | Write organization-wide app data | Storage API - App Data | Includes read |
userdata:read | Read user-specific app data | Storage API - User Data | Read only |
userdata:write | Write user-specific app data | Storage API - User Data | Includes read |
usercollection:read | Read user data collections | Storage API - Collections | Read only |
usercollection:write | Write to user data collections | Storage API - Collections | Includes read |
Important: Write permissions (*:write) automatically grant read access. Requesting *:write is sufficient for both reading and writing.
AI & Feature Permissions
| Permission | Description | Access Type |
|---|---|---|
ai:text_generate | Generate text using AI models | AI Generation API |
ai:context_external_send | Send platform data to AI models | AI Context Sharing |
Realtime Permissions
| Permission | Description | Access Type |
|---|---|---|
realtime | Publish and subscribe to the app's realtime channels | Realtime SDK |
Public API Permissions
These permissions grant your app's servers access to the Teachfloor public API via the OAuth token. They are not available through the SDK — only your backend can use them by calling https://api.teachfloor.com/v0/* with the app's access token.
| Permission | Description | Access Type |
|---|---|---|
members:read | Read organization members and their course enrollments | Public API only |
activities:read | Read activity records generated by members | Public API only |
Note that courses:read, modules:read, and elements:read also unlock the matching public-API endpoints (GET /v0/courses/*, etc.) when your app opts into OAuth. See OAuth for the complete manifest-permission → OAuth-scope mapping.
Permission Details
User Permissions
user:read
Access basic user profile information.
Data available in objectContext:
- User ID
- Full name
- Email address
- Avatar URL
- Language preference
- Timezone
Use cases:
- Personalization
- User greetings
- Profile displays
Example:
Code
user_events:read
Access user activity and learning events.
Data available in objectContext:
- Course enrollments
- Module completions
- Element interactions
- Login history
- Activity timestamps
Use cases:
- Progress tracking
- Analytics dashboards
- Activity feeds
- Engagement metrics
Example:
Code
Contextual Permissions
These permissions control what data appears in the objectContext parameter based on the current viewport.
courses:read
Access course information when user is in a course viewport.
Data available in objectContext.course:
- Course ID
- Course title
- Description
- Status
- Enrollment data
- Course settings
Available in viewports:
teachfloor.dashboard.course.detailteachfloor.dashboard.course.module.detailteachfloor.dashboard.course.element.detail
Example:
Code
Usage:
Code
modules:read
Access module information when user is viewing a module.
Data available in objectContext.module:
- Module ID
- Module title
- Description
- Order/sequence
- Completion status
Available in viewports:
teachfloor.dashboard.course.module.detailteachfloor.dashboard.course.element.detail
Example:
Code
Usage:
Code
elements:read
Access learning element information when user is viewing an element.
Data available in objectContext.element:
- Element ID
- Element type (video, assignment, quiz, etc.)
- Title and description
- Content metadata
- Completion status
Available in viewports:
teachfloor.dashboard.course.element.detail
Example:
Code
Usage:
Code
Storage Permissions
Storage permissions allow your app to persist data on the Teachfloor platform. See Data Storage for detailed usage.
appdata:read & appdata:write
Store and retrieve organization-wide app data shared across all users.
Permission Hierarchy: appdata:write includes appdata:read access.
Use cases:
- App configuration
- Global settings
- Shared templates
- Feature flags
Example (Read and Write):
Code
Example (Read-Only):
Code
Usage:
Code
userdata:read & userdata:write
Store and retrieve user-specific data.
Permission Hierarchy: userdata:write includes userdata:read access.
Use cases:
- User preferences
- Personal settings
- User state
- Draft content
Example (Read and Write):
Code
Example (Read-Only):
Code
Usage:
Code
usercollection:read & usercollection:write
Store and retrieve collections of data items for a user, with pagination support.
Permission Hierarchy: usercollection:write includes usercollection:read access.
Use cases:
- Activity logs
- User notes or annotations
- Saved items
- History data
Example (Read and Write):
Code
Example (Read-Only):
Code
Usage:
Code
AI Permissions
ai:text_generate
Generate text using AI language models.
Use cases:
- Content generation
- Text completion
- Summarization
- Translation
Example:
Code
Usage:
Code
ai:context_external_send
Permission to use platform data placeholders in AI prompts.
How it works: This permission is only checked when you use placeholders like {{course.name}} or {{module.content}} in your AI prompts. Without this permission, you can still use generate() with regular prompts.
Supported Placeholders:
{{course.name}}- Course title{{course.content}}- Course content (text format){{module.name}}- Module title{{module.content}}- Module content (text format){{element.name}}- Element title{{element.content}}- Element content (text format)
Important: When using placeholders, you must also have the corresponding read permission:
- Course placeholders require
courses:read - Module placeholders require
modules:read - Element placeholders require
elements:read
Example:
Code
Usage:
Code
Realtime Permission
realtime
Publish and subscribe to your app's realtime channels. Enables sub-second event delivery between an app's SDK views (widgets, drawers, pages) while learners are active.
Use cases:
- Live collaboration UIs (cursors, presence, live-edit)
- Broadcasting state changes from one widget instance to others
- Instructor-side dashboards that react to learner activity in real time
Example:
Code
Usage:
Code
Subscribing to a course-scoped channel additionally needs courses:read (and the same pattern for modules:read / elements:read) — without it, the host strips the resource id from the viewport payload and there's no id to subscribe with. See Realtime Channels for the full channel model, event shape, and delivery guarantees.
Public API Permissions
These permissions apply only to server-to-server calls via the app's OAuth token — they don't expose data through the SDK. Your app needs to opt into OAuth (see OAuth) for them to have any effect.
members:read
Read organization members and their course enrollments via the public API.
Grants access to:
GET /v0/members— list all membersGET /v0/members/search— search membersGET /v0/members/{id}— fetch a specific memberGET /v0/members/{id}/courses— list a member's course enrollments (requirescourses:read)GET /v0/courses/{id}/members— list members enrolled in a course (requirescourses:read)GET /v0/courses/{id}/members/{member_id}— fetch a specific enrollment (requirescourses:read)
Use cases:
- Sync members into an external CRM or HR system
- Reporting on enrollment across your customer base
Example:
Code
activities:read
Read activity records generated by members interacting with course elements.
Grants access to:
GET /v0/activities— list all activitiesGET /v0/activities/{id}— fetch a specific activityGET /v0/elements/{id}/activities— list activities for a given element (requireselements:read)
Use cases:
- Feed learner progress into an external analytics dashboard
- Trigger downstream automations when specific activity types occur
Example:
Code
Permission Management
Adding Permissions
Using CLI
Code
Select permission and enter purpose when prompted.
Manual Addition
Edit teachfloor-app.json:
Code
Removing Permissions
Using CLI
Code
Manual Removal
Remove from manifest:
Code
Permission Purposes
Each permission must have a clear, user-facing explanation.
Good purposes:
- "Display course information in your notes" ✓
- "Show your current module progress" ✓
- "Track your learning progress for analytics" ✓
Poor purposes:
- "Access data" ✗ (too vague)
- "Platform integration" ✗ (not user-facing)
- "Required for functionality" ✗ (not specific)
Using Permissions
Always check if contextual data exists before accessing it:
Code
See Integration Guide - Events for complete objectContext usage examples.
Next Steps
→ Continue to Deployment
Additional Resources
- Integration Guide - Using permissions with events and storage
- Best Practices - Permission best practices and patterns
- Examples - Complete permission usage examples