Instructor Dashboard - Course Information API

[wgu-jesse-stewart]

While /api/courses/v1/ provides learner-facing course information, these instructor-specific endpoints provide administrative data (enrollment counts by mode, instructor tasks, pricing management) that require instructor permissions.

Method	Endpoint	Services	Status	Existing API Path	Description
GET	/api/instructor/v1/courses/{course_key}	instructor, xmodule.modulestore	Missing	N/A	Retrieve course metadata including enrollment counts and settings
GET	/api/instructor/v1/courses/{course_key}/instructor_tasks	instructor_task	Partial	/api/instructor/v1/tasks/{course_id}	List background tasks for the course
GET	/api/instructor/v1/courses/{course_key}/modes	course_modes	Missing	On-Hold	Retrieve enrollment modes and pricing for the course
PATCH	/api/instructor/v1/courses/{course_key}/modes/{mode_id}/price	course_modes	Missing	On-Hold	Update pricing for a specific enrollment mode

[awais786]

Hi @wgu-jesse-stewart, I’m interested in contributing to these tickets. Could you please let me know how I can help or where to get started?

[wgu-jesse-stewart]

I've created the swagger docs for this endpoint. I've started implementing it. @awais786, would you like to pickup and endpoint and start working on it? Let me know what assistance you need.

Courses

Course metadata and enrollment information
/courses/{course_key}

Retrieves comprehensive instructor-specific course information including:

• Course metadata and dates
• Enrollment counts by mode
• Dashboard navigation sections and permissions
• Studio URL and feature flags

This endpoint serves as the primary initialization call for the instructor dashboard MFE, providing all the data needed to configure the UI and determine what features are available to the current user.

Required Permission: View access to instructor dashboard (staff or instructor role)

Use Cases:

• Initialize instructor dashboard MFE on page load
• Display course overview and enrollment statistics
• Configure navigation tabs based on user permissions
• Determine which features to enable/disable

Example Response:

{
  "course_id": "course-v1:edX+DemoX+2024",
  "display_name": "Demonstration Course",
  "org": "edX",
  "course_number": "DemoX",
  "enrollment_start": "2024-01-01T00:00:00Z",
  "enrollment_end": "2024-12-31T23:59:59Z",
  "start": "2024-01-15T00:00:00Z",
  "end": "2024-06-30T23:59:59Z",
  "pacing": "instructor",
  "has_started": true,
  "has_ended": false,
  "total_enrollment": 1250,
  "enrollment_counts": {
    "audit": 1000,
    "verified": 250,
    "total": 1250
  },
  "num_sections": 12,
  "grade_cutoffs": "A is 0.9, B is 0.8, C is 0.7, D is 0.6",
  "course_errors": [],
  "studio_url": "https://studio.example.com/course/course-v1:edX+DemoX+2024",
  "permissions": {
    "admin": false,
    "instructor": true,
    "finance_admin": false,
    "sales_admin": false,
    "staff": true,
    "forum_admin": true,
    "data_researcher": false
  },
  "tabs": [
    {
      "tab_id": "courseware",
      "title": "Course",
      "url": "/courses/course-v1:edX+DemoX+2024/courseware"
    },
    {
      "tab_id": "progress",
      "title": "Progress",
      "url": "/courses/course-v1:edX+DemoX+2024/progress"
    },
    {
      "tab_id": "dates",
      "title": "Dates",
      "url": "/courses/course-v1:edX+DemoX+2024/dates"
    },
    {
      "tab_id": "discussion",
      "title": "Discussion",
      "url": "/courses/course-v1:edX+DemoX+2024/discussion/forum"
    },
    {
      "tab_id": "teams",
      "title": "Teams",
      "url": "/courses/course-v1:edX+DemoX+2024/teams"
    },
    {
      "tab_id": "instructor",
      "title": "Instructor",
      "url": "/courses/course-v1:edX+DemoX+2024/instructor"
    },
    {
      "tab_id": "ccx_coach",
      "title": "CCX Coach",
      "url": "/courses/course-v1:edX+DemoX+2024/ccx_coach"
    }
  ],
  "disable_buttons": false,
  "analytics_dashboard_message": "To gain insights into student enrollment and participation..."
}

[awais786]

Yes, I can pick this story.

[wgu-jesse-stewart]

@awais786 - Sure, I updated the spec with what we know right now. A few key points:
What's changing:

• We won't need a PATCH endpoint
• I've put /modes on hold since we aren't sure yet where this is used in the UI
• We're creating a new app at edx-platform/lms/djangoapps/instructor_v2 so we can cleanly deprecate the old code

Resources:

Redesign: Figma link
Corresponding front-end story: openedx/frontend-app-instructor-dashboard#9

Important note: There are still a lot of unknowns here, this spec is my best guess with the information I have. We'll need to remain flexible as the front-end is built out.

[wgu-jesse-stewart]

I started with creating a swagger doc for this endpoint that I was building from:

instructor-course-info-api-spec.yaml

[jacobo-dominguez-wgu]

@wgu-jesse-stewart, @awais786 Quick question, I am currently working on the frontend part for the enrollments summary openedx/frontend-app-instructor-dashboard#25, in the example response I do not see the in the enrollment_counts the values for staff/admin and learners, where do I get that data?

[wgu-jesse-stewart]

@jacobo-dominguez-wgu You can find the story for that endpoint at: #37466 - We haven't written the specification for the /enrollments endpoint yet

[jawad-khan]

@wgu-jesse-stewart
I’d like to pick up this task and start implementing the required APIs.

After reviewing the feature description and existing code structure, I believe we do not need to create a separate Django app for these endpoints. The functionality aligns closely with the existing instructor app (lms/djangoapps/instructor), since:

The new APIs are instructor-facing (e.g., course management, learner data, analytics) and logically belong in the same domain.

We can reuse existing models, serializers, and permission classes (IsInstructor, CourseStaffOrSuperuser, etc.), reducing duplication and keeping related logic in one place.

Proposed approach:

Add the new endpoints under the existing instructor app’s URL patterns (e.g., /api/instructor/v1/courses/{course_id}/...).

Follow existing code patterns and conventions for views, serializers, and tests.

If any URL or endpoint naming conflicts arise with existing APIs, we can move forward using API versioning (for example, introducing /api/instructor/v2/...).

Over time, older versions can be deprecated gracefully after a transition period, ensuring backward compatibility for existing clients.

This approach keeps the codebase clean, avoids unnecessary new apps, and supports a smooth evolution path through versioning if required.

[wgu-jesse-stewart]

Hi @jawad-khan thank you for the thoughtful review and for outlining a clear proposal. You raise a valid point: structurally, these endpoints do align with existing instructor-facing functionality, and reusing serializers, permissions, and patterns within lms/djangoapps/instructor would help avoid duplication and reduce immediate overhead.

My primary concern with adding to the existing app is ensuring that we don’t introduce regressions or increase tech debt in the long term. Since part of our broader goal is to modernize and eventually deprecate the legacy Instructor Dashboard, I was aiming to isolate new work into a dedicated instructor_v2 app so we could:

Build cleanly without being constrained by legacy patterns

Migrate feature-by-feature to the MFE without impacting existing consumers

Allow old and new APIs to coexist during a transition, without conflicts

That said, you’re correct that versioning could accomplish the same separation if implemented cleanly (e.g., /api/instructor/v2/...), and may reduce the startup cost of a new app.

Before we commit to one approach, it would be good to confirm the intended architectural direction so we don’t end up maintaining two “instructor” apps indefinitely.

Looping in @feanil for perspective:
Do you have guidance or a preference on whether we should (A) introduce a separate instructor_v2 Django app to house the new API surface, or (B) evolve the current instructor app using versioning and cleanup over time?

Either approach works, we just want to set this up in a way that future deprecation and migration is smooth for both the legacy dashboard and the new MFE.

[diana-villalvazo-wgu]

I've created the swagger docs for this endpoint. I've started implementing it. @awais786, would you like to pickup and endpoint and start working on it? Let me know what assistance you need.

Courses

Course metadata and enrollment information /courses/{course_key}

Retrieves comprehensive instructor-specific course information including:

• Course metadata and dates
• Enrollment counts by mode
• Dashboard navigation sections and permissions
• Studio URL and feature flags

This endpoint serves as the primary initialization call for the instructor dashboard MFE, providing all the data needed to configure the UI and determine what features are available to the current user.

Required Permission: View access to instructor dashboard (staff or instructor role)

Use Cases:

• Initialize instructor dashboard MFE on page load
• Display course overview and enrollment statistics
• Configure navigation tabs based on user permissions
• Determine which features to enable/disable

Example Response:

{
  "course_id": "course-v1:edX+DemoX+2024",
  "display_name": "Demonstration Course",
  "org": "edX",
  "course_number": "DemoX",
  "enrollment_start": "2024-01-01T00:00:00Z",
  "enrollment_end": "2024-12-31T23:59:59Z",
  "start": "2024-01-15T00:00:00Z",
  "end": "2024-06-30T23:59:59Z",
  "pacing": "instructor",
  "has_started": true,
  "has_ended": false,
  "total_enrollment": 1250,
  "enrollment_counts": {
    "audit": 1000,
    "verified": 250,
    "total": 1250
  },
  "num_sections": 12,
  "grade_cutoffs": "A is 0.9, B is 0.8, C is 0.7, D is 0.6",
  "course_errors": [],
  "studio_url": "https://studio.example.com/course/course-v1:edX+DemoX+2024",
  "permissions": {
    "admin": false,
    "instructor": true,
    "finance_admin": false,
    "sales_admin": false,
    "staff": true,
    "forum_admin": true,
    "data_researcher": false
  },
  "sections": [
    {
      "section_key": "course_info",
      "section_display_name": "Course Info",
      "is_hidden": false
    },
    {
      "section_key": "membership",
      "section_display_name": "Membership",
      "is_hidden": false
    },
    {
      "section_key": "student_admin",
      "section_display_name": "Student Admin",
      "is_hidden": false
    }
  ],
  "disable_buttons": false,
  "analytics_dashboard_message": "To gain insights into student enrollment and participation..."
}

Regarding this example response, sections is for instructor tabs? can we follow same response structure that we are having for course navigation tab bar? And also as we already talked Jesse i will need this tab info on every tab (just in case someone lands directly to a diff tab), so the call to endpoint with tab info should be on this endpoint or can we have a generic one as course is handling the metadata on /api/course_home/course_metadata/:courseId?