Loopwise Docs

Scopes define what data an OAuth application can access. Request only the scopes your integration needs.

Identity scopes (OIDC)

These scopes follow the OpenID Connect Core 1.0 specification and provide access to user identity information via the UserInfo endpoint.

Scope	Description
`openid`	Required for identity access. Returns the user's unique identifier (`sub` claim), and — when the token has a school context — the `org_id` (school identifier) and `roles` (user's roles on that school, ordered by privilege; may be empty if the user has no roles there). This is the default scope.
`profile`	Access the user's name and profile picture
`email`	Access the user's email address and verification status

The org_id and roles claims are OIDC extension claims (see UserInfo endpoint for the full claim schema and ordering contract). They let agents and OAuth integrations read "which school + which role" directly from the standard userinfo response — no extra request to admin GraphQL required for the common onboarding case.

Account scopes

These scopes unlock the Member API at {school}/member/graphql — one signed-in member's own data, rather than a whole school's admin surface. Useful when a user belongs to multiple schools and the integration needs to enumerate them. See the AI Agent Integration guide for the canonical multi-school query example.

enrolledCourses, digitalProducts and eventRegistrations answer what a member has access to. They are not order records — no order number, coupon code, refund status or invoice — so do not build a billing history from them. Build it from viewer.payments, which is on the same endpoint under the same scope and carries all four. One node there is one payment, and tradeNo identifies that payment rather than the purchase behind it: a retried checkout is a separate node with a different tradeNo, and nothing joins the attempts of one purchase together.

consultingServices is not a purchase list at all: it returns the services offered against the courses delivered to the viewer, and its meetings are every undiscarded meeting under the service — booked or not, nobody's in particular — with no field saying which are the viewer's.

Scope	Description
`account:read`	Read the authenticated user's account context: school memberships (including roles per school), enrolled courses, digital products, consulting services, event registrations, the member's own payments, and the member's own notification inbox, unread count and per-type subscriptions
`account:write`	Update the authenticated user's own notification state: mark one notification or all of them as read, and change the in-app and email opt-in for a notification type. Nothing else on the Member API is writable.

Data scopes

These scopes control access to school data through the API.

Scope	Description
`courses:read`	Read course details, curriculum, and enrollment data
`courses:write`	Create, update, and delete courses
`students:read`	Read student profiles and progress data
`students:write`	Create and update student records, manage enrollments
`analytics:read`	Read analytics and reporting data
`curriculum:read`	Read curriculum structure (lessons, chapters, materials)
`curriculum:write`	Create and update curriculum content
`orders:read`	Read order and payment data
`school:read`	Read school configuration and settings
`school:write`	Update school configuration and settings
`appearance:read`	Read school appearance and theme settings
`appearance:write`	Update school appearance and theme settings
`events:read`	Read event details and attendees
`events:write`	Create, update, and delete events
`membership_plans:read`	Read membership plan details
`membership_plans:write`	Create and update membership plans
`coupons:read`	Read coupon details
`coupons:write`	Create and update coupons
`posts:read`	Read post content
`posts:write`	Create, update, and delete posts
`digital_products:read`	Read digital download details
`digital_products:write`	Create and update digital downloads
`comments:read`	Read comments
`lecturers:read`	Read lecturer profiles
`lecturers:write`	Create and update lecturer profiles
`storage:write`	Upload files and images
`subscriptions:read`	Read subscription data
`subscriptions:write`	Manage subscriptions

MCP tool to scope mapping

When using the MCP server, each tool requires a specific OAuth scope. Note that MCP tool names may differ from scope names (e.g. list_members requires students:read).

MCP Tool	Required Scope
`list_courses`, `get_course`, `list_reviews`	`courses:read`
`update_course`	`courses:write`
`list_members`, `get_member`	`students:read`
`get_site_info`	`school:read`
`get_settings`	`school:read` or `appearance:read`
`update_settings`	`school:write` or `appearance:write`
`list_orders`	`orders:read`
`list_lessons`	`curriculum:read`
`list_membership_plans`, `get_membership_plan`	`membership_plans:read`
`list_events`, `get_event`, `list_event_attendees`	`events:read`
`list_coupons`, `get_coupon`	`coupons:read`
`list_posts`, `get_post`	`posts:read`
`create_post`, `update_post`, `delete_post`	`posts:write`
`list_digital_downloads`, `get_digital_download`	`digital_products:read`
`list_comments`, `get_comment`	`comments:read`
`upload_image`, `confirm_upload`	`storage:write`
`list_lecturers`, `get_lecturer`	`lecturers:read`
`create_lecturer`, `update_lecturer`	`lecturers:write`

Some tools are accessible via multiple scopes. For example, get_settings is available with either school:read or appearance:read.

Requesting scopes

Include the desired scopes as a space-separated list in the scope parameter of the authorization request:

/oauth/authorize?scope=openid+profile+email+courses:read+students:read&...

If no scopes are specified, only openid is granted by default.

Scope hierarchy

Use the most restrictive scopes possible for your use case. This follows the principle of least privilege and makes the consent screen clearer for users.

For example, if your integration only needs to read course data and the user's email, request openid email courses:read rather than requesting all available scopes.

Admin scopes

The admin:read and admin:write scopes are reserved for platform administrators and are not available to third-party applications. They are excluded from the discovery endpoint and dynamic client registration responses.

Scopes