An Extensible Core Platform that accelerates the evolution (via rapid development and experimentation) of platform features supports integrations in the frontend, backend, and to/from external services. As shown in the diagram and table below, a combination of technologies enables various integrations.

Diagram Link

API Type	Status	Description	Use Cases	Technology Examples
Real-time Events: xAPI/Caliper	In Progress	EdTech industry-standard mechanism for communicating real-time learning events to any standard-conforming consumer. See OEP-26: Real-time Events. Typically, the consumer leverages its own Learning Record Store as a mechanism to capture and query learning events, sometimes across multiple LMSes. Not only could this be a future replacement for today's latent batch delivery of tracking logs to university partners, but this also enables future data integrations with 3rd party EdTech tools. In the short term, universities and enterprises can leverage this capability to receive real-time learner and course data.	Enterprise & University integrations Learning Science Research Integrations EdTech Tool Integrations Adaptive Learning	xAPI/Caliper, Web Sockets, Kafka
Real-time Events: Segment → Destinations	Exists	Segment.io is an external service that stores and routes real-time events to configurable 3rd party destinations.	Email Notifications, Push Notifications Data Analysis Tool Integrations	Segment → Braze, Segment → Google Analytics
Frontend Plugin APIs	In Progress	Also known as Experience Plugins, the Frontend Plugin framework will allow 3rd party Javascript components to enhance the platform's front-end experience. The plugin code runs within the web browser, preferably within a secure sandbox such as an iFrame. These Plugins would interact and leverage the underlying data and experience of the frontend page through well-defined plugin APIs of platform Frontend Events and platform JS Libraries.	Developers want to efficiently add experiments to relatively complex frontends with minimal need for inter-team communications. Developers want to add widgets to a core frontend experience (on a dashboard or on a sidebar of a page). Developers create platform extensions that can be selected by Course Teams and Operators. Course Teams modify their course experiences for learners, authors, and admins. Learners build and/or select extensions to customize their own learning experiences.	Web Components, LTI, Webpack's Module Federation
Frontend Theming	Some support	The Theming framework allows Operators to customize the look-and-feel of the frontend experience without modifying the core platform. The concept of Theming is decomposed into multiple layers in order to provide decoupled and simpler building blocks, each serving different needs: Branding, Configuration, Customization.	For Open edX Operators: Branding - modify colors, logos, styles Configuration - modify settings and variables Customization - override modular components within the page with custom ones	Paragon branding, Webpack config, NPM override
Feature-driven APIs	Exists	APIs provided by backend microservices for focused single responsibility of a feature, to be consumed by the feature's frontend experiences (mobile or web apps). See API Trichotomy Proposal for where this class of APIs fits in the tiered support level for APIs.	MFE or Mobile app accesses or manipulates data in a backend service	REST, GraphQL
Backend Plugin APIs	Some support	APIs that enable long-term maintenance and support of Django App Plugins. While the Django App Plugin framework allows developers to extend backend services without modifying them, the Plugins need APIs they can rely on with decoupled communication structures. Open edX Django Events provide an event-based API where the backend core notifies plugin consumers. Open edX Django Filters, inspired by Wordpress Filters capability, provide an ability to configure a pipeline of data manipulators at pre-defined integration points in the backend core. We will also want a framework for Supported Python APIs that backend plugins can synchronously call within the backend core.	Efficiently add support for a new business use case that needs backend changes. Customization to the base offering for a specific enterprise, without modifying the core platform. Ongoing maintenance of backend extensions, such as Course Dates and Course Completions.	Django App Plugins, Wordpress Filters, Django Events, Django Filters, Python APIs
Content Plugin APIs	Exists	Content Plugins can leverage the Backend Plugin and Frontend Plugin frameworks for their implementations but their purpose is specifically for authoring the course content. The XBlock framework was developed early in edX's history for this purpose, including frameworks for custom graders (Codejail, XQueue).	Authoring rich course content Creating problem banks Creating custom graders	XBlock, Graders
Inter-service Bus Events	In Progress	An event bus is a way of allowing us to independently spin up new services without destabilizing our existing offerings. It reduces the coupling between our systems which allows them more autonomy and greater scalability, reducing the risk of systems bringing each other down with unexpected workloads. It provides a path to reduce the size and complexity of our edx-platform monolith, which in turn reduces overall development costs and time to market. It also enables innovation in the Open edX ecosystem through the same decoupling, allowing developers to access data and events via supported, well-defined APIs rather than relying on edx-platform internals or forking the code.	Breaking up the monolith by decoupling its data communications Adding a new service to address a new business need Scaling the organization with services appropriately sized for a team's cognitive load	Pulsar/Kafka, Docker/Kubernetes
Service & Business APIs	Exists	These are synchronous Public APIs that cross organizational boundaries and denote the higher tiers of the API Trichotomy Proposal. Since these APIs are not industry standards, we need to properly define them, document them, support and maintain them - essentially treat these APIs as their own Products.	Proctoring API and plugin interface Registrar API Affiliates API	REST
Content Integrations	Exists	While the EdTech industry innovates and competes, they are leveraging standards to interoperate across platforms. In particular, they have standards for integrating and transporting content from one platform to another. This enables course teams to efficiently migrate content and offer their courses on multiple sites. LTI enables the embedded use of a learning component on a frontend page, while it remains hosted on another site. Scorm and Common Cartridge enable exporting and importing content from one site to another. OLX is an Open edX proprietary standard that serves a similar purpose to Scorm and Common Cartridge.	Course team offers the same content on multiple EdTech sites Course team offers the same content on-campus and online Course team ports content from one site to another	OLX, LTI, Scorm, Common Cartridge
Data Reporting APIs	Does Not Exist	A cross-organizational interface to access data and reports of various platform domain concepts, such as Courses, Users, Completions, etc. This class of API does not exist today. We have some universities accessing our data through other means (synchronous paginated REST APIs or manually accessed through Admin UIs), which are probably better served through a dedicated API for this purpose. Note: This capability of downloading bulk data contrasts with the "Real-time Events: xAPI/Caliper" capability listed above, which is for receiving real-time singular events.	University admin wanting to integrate data from our platform with their SIS system Enterprise L&D admin wanting to integrate data from our platform with another platform Course team wanting to download latest data on their course results	GraphQL, REST, Data Mart APIs

Browser not supported