APIs & Integration

Overview

APIs & Integration covers the developer-facing interfaces for integrating with Open edX — REST APIs, the Open edX Events framework (OEP-41), Open edX Filters/Hooks (OEP-50), and the event bus infrastructure. These are the primary tools developers use to build on top of the platform without modifying its core.

Together, the REST APIs, events, and filters form a layered integration model: REST APIs for synchronous data exchange, events for async notifications, and filters for intercepting and modifying platform behavior.

Current State (2026)

• REST APIs: edx-platform exposes REST APIs for enrollment, courses, grades, users, and more; versioned at /api/[service]/v[N]/
• Open edX Events (OEP-41): openedx-events defines AsyncSignal events; emitted at key platform moments (enrollment, login, course publish); can be consumed locally or via event bus
• Open edX Filters (OEP-50): openedx-filters provides pipeline-based hooks; Django plugins register filter steps to intercept and modify platform behavior
• Event bus: event-bus-kafka or event-bus-redis bridges Open edX Events to external consumers; enables microservice integration
• API versioning: APIs versioned; breaking changes require new API version; edx-drf-extensions standardizes auth, pagination

Architecture

• REST API pattern: Django REST Framework (DRF); JWT authentication via edx-drf-extensions; consistent pagination and error formats
• Event emission: openedx-events AsyncSignal emitted via Django signals in platform code; event-routing-backends routes to ClickHouse, Kafka, etc.
• Filter pipeline: openedx-filters registers Python callables; platform code calls filter at hook points; callables can modify or abort actions
• Event bus: Kafka/Redis bridge converts Django signals to serialized events; external consumers subscribe to topics

Relevant Repositories

Repository	Role in This Feature	Activity Level	Notes
openedx/openedx-platform	Primary REST API surface	High	Most developer-facing APIs
openedx/openedx-events	AsyncSignal event definitions (OEP-41)	High	Event framework
openedx/openedx-filters	Hooks & Filters (OEP-50)	High	Behavior interception
openedx/edx-drf-extensions	DRF extensions: JWT auth, pagination	Medium	API standards
openedx/event-bus-kafka	Kafka event bus backend	Medium	Async integration
openedx/event-bus-redis	Redis Streams event bus	Medium	Lighter alternative
openedx/api-doc-tools	API documentation generation	Low	Dev tooling

Recent Changes

• Open edX Events and Filters increasingly adopted as the standard extension mechanism
• Event bus enabling microservice-style integration patterns

History

Origin

• Year introduced: 2013+ (REST APIs gradually added; events/filters are newer)
• Initial implementation: Django views with JSON responses; gradually formalized into DRF-based REST APIs
• Context: External developers (edX partners, community) needed programmatic access; REST APIs emerged from that need

Key Milestones

Year	Milestone	Teams / People Involved
~2013–2014	REST APIs formally added to edx-platform	Unknown
~2018	OEP-41 (Events) proposed	Unknown
~2019–2020	openedx-events developed	Unknown
~2020–2021	OEP-50 (Filters/Hooks) and openedx-filters	Unknown
~2021–2022	Event bus (Kafka/Redis) implementation	Unknown

People Who Shaped This Area

• Engineering: Unknown — key OEP authors to document
• Product: Unknown — open question for interview
• Design: N/A (developer API area)

Open Questions

• [ ] Who authored OEP-41 (Events) and what was the design process?
• [ ] Who authored OEP-50 (Filters/Hooks) and how does it differ from Django signals?
• [ ] Why was Kafka chosen as the event bus backend? What were the alternatives considered?
• [ ] How do the REST APIs handle backward compatibility across major releases?
• [ ] What are the most commonly used APIs by third-party integrators?
• [ ] How does the event schema versioning work across openedx-events?