Open edX Webhooks

Purpose

Webhooks for Open edX.

Current compatibility target: Open edX Verawood / Tutor 22.x.

This plugin implements a generic case of event handling that triggers a request to a configurable URL when a signal is received.

Getting Started

Introduction

A Webhook triggers an HTTP POST request to a configurable URL when certain events happen in the platform, including information relevant to the event. For example, you can make the platform call an API when a user logs in, including the user ID and email to connect to another application.

A Webfilter is a special case of webhook that can also modify data and/or interrupt the process. For example, after the user login event you can update the user full name or prevent the user from logging in.

Deploying

To install this plugin into an Open edX instance installed by Tutor, add this line to the OPENEDX_EXTRA_PIP_REQUIREMENTS list in config.yml.

OPENEDX_EXTRA_PIP_REQUIREMENTS:
  - openedx-webhooks

This release targets Open edX Verawood and Tutor 22.x, which use Python 3.12.

After rebuilding the Open edX image with the updated package, run migrations before restarting LMS, Studio, and their workers:

tutor {dev|local|k8s} exec lms ./manage.py lms migrate

This plugin now registers extension points in both LMS and CMS. Webhook and webfilter configuration is still managed through Django admin and the same database tables.

Migration 0008_verawood adds the current event choices and corrects ten old filter names that did not match their handlers. Existing URLs and controls are preserved. Corrected configurations that previously never fired will now become active; review enabled endpoints before upgrading. The migration does not convert legacy instructor dashboard customizations into MFE tabs. Keep package version 21 for Ulmo deployments.

Configuring

A new section named OPENEDX_WEBHOOKS is available in the LMS Django admin site. It contains two subsections: Webhooks and Webfilters. Add a new webhook to define the URLs that will be called after each event is received. More than one URL can be configured for each event. In that case, all URLs are called.

Configuring Webhooks

The Webhooks Django admin panel has the following settings:

• Event: Choose from the list the event that will trigger the webhook.
• Webhook URL: URL to call. Get it from your webhook processor.
• Enabled: Click to enable the webhook.
• Use WWW form encoding: When enabled, the data will be passed in web form format. If disabled, data will be passed in JSON format.

Configuring Webfilters

The Webfilters Django admin panel has the following settings:

• Description: Add a description for this webhook for reference.
• Event: Choose from the list the event that will trigger the webhook.
• Webhook URL: URL to call. Get it from your webhook processor.
• Enabled: Click to enable the webhook.
• Disable filtering: If enabled, the data passed to the web filter will not be modified even if the response includes any update.
• Disable halting: If enabled, the process will not be interrupted even if the response includes an exception setting.
• Halt on 4xx: Interrupt the process if the call to the URL returns any 4xx error code.
• Redirect on 4xx: Include a URL to redirect in case of a 4xx response, if the event supports redirection.
• Halt on 5xx: Interrupt the process if the call to the URL returns any 5xx error code.
• Redirect on 5xx: Include a URL to redirect in case of a 5xx response, if the event supports redirection.
• Halt on request exception: Interrupt the process if the call to the URL results in a connection error such as a timeout.
• Redirect on request exception: Include a URL to redirect in case of a connection error, if the event supports redirection.
• Use WWW form encoding: When enabled, the data will be passed in web form format. If disabled, data will be passed in JSON format.

Receiving Data

Both webhooks and webfilters trigger POST requests to the configured URL. The payload includes data relevant to the event that triggered the call. In all cases, the payload includes an event_metadata key with at least the event type and the date and time in UTC format. Other keys depend on the event. For example, login events usually include user and profile keys with details of the user logging in.

Signal webhooks retain their existing envelope: the data key is the fully qualified upstream data class, such as openedx_events.authz.data.RoleAssignmentData, alongside event_metadata. Webfilters use argument-specific keys such as user and profile.

Credential fields (including passwords and password hashes) are omitted from outgoing payloads. Remote model updates cannot change primary keys, relationships, passwords, or account privilege flags. Other personal data is intentionally sent to configured endpoints; restrict configuration access to trusted administrators.

If the Use WWW form encoding option is enabled, the data is passed as plain key-value pairs in form encoding. The structure is flattened and the key names are concatenated. For example, a login event includes user_id, user_email, event_metadata_time, and similar fields.

Responding to Webfilters

The webhook processor should respond to a webfilter with a JSON structure and a successful status code (200). The response can be empty or can have one or both of these keys:

• data
• exception

Updating Data

The corresponding objects are updated with the values returned inside the data key. Only keys present in the response are updated. Other keys remain unchanged in the original data structures. To disable data updates, set Disable Filtering in the webfilter configuration in the Django admin panel.

For example, to change the full name of a user at registration time, respond to the Student Registration Requested webfilter with this data:

{
  "data": {
    "form_data": {
      "name": "New Name"
    }
  }
}

Interrupting Execution

To stop the process, add a JSON object as the value for the exception key. This object must have only one key-value pair: the key is the name of the exception to raise, and the value can be either a string representing the message to show or another JSON object with more data.

For example, to prevent a user from registering, respond to the Student Registration Requested webfilter with this data:

{
  "exception": {
    "PreventRegistration": "Not allowed to register"
  }
}

To prevent a webfilter from stopping the process, set Disable halting in the webfilter configuration in the Django admin panel.

Check each function documentation to see the list of available values and exceptions.

Handling Multiple Events

If you set more than one webhook or webfilter for the same event, all of them are triggered. The responses of all webfilters are combined into one data structure and used to update the objects. If more than one webfilter processor includes data for the same key, the last one overrides the previous ones.

Endpoints run in ascending configuration ID order. Signal delivery failures are logged and delivery continues to the other endpoints. Delivery is synchronous, with ten-second connection and response-read timeouts, and has no persistent retries. These timeouts are not a total request deadline; an endpoint that keeps sending data can block delivery for longer than ten seconds. Webfilters retain their configured halting behavior; filters with no upstream exception cannot halt through the transport-error controls.

Developing

More information about available signals can be found in the events documentation and the filters documentation.

Verawood compatibility in this package is aligned with:

• openedx-filters==3.4.1
• openedx-events==11.2.0

The runtime is Python 3.12 with Django 5.2; tests pin Django 5.2.13 from the Verawood platform requirements.

New filters are InstructorDashboardTabsRequested, AccountSettingsReadOnlyFieldsRequested, and GradeEventContextRequested. New ROLE_ASSIGNMENT_CREATED and ROLE_ASSIGNMENT_DELETED webhook events are registered in both LMS and Studio. Existing learning and authoring signal names and receiver arguments are unchanged. Discussion payloads now include enabled; forum IDs are strings and several forum fields may be null.

For the new instructor dashboard, configure InstructorDashboardTabsRequested and return {"data": {"tabs": [{"tab_id": "reports", "title": "Reports", "url": "https://example.com/reports"}]}}. This replaces the tabs list (including with an empty list); include any existing tabs you wish to keep. Its filter identifier is org.openedx.learning.instructor.dashboard.tabs.requested.v1 in the pinned source, despite the tabs.generated.v1 identifier mentioned in the release notes. Legacy InstructorDashboardRenderStarted remains available only when the legacy dashboard is enabled. Frontend plugin configuration is still needed to render custom content inside the MFE.

For account restrictions, return {"data": {"readonly_fields": ["name", "email"]}}. These names are added to existing restrictions; the pipeline retains a Python set. For grade event enrichment, return {"data": {"context": {"source": "crm"}}}. The context is merged while retaining the original user and course identifiers. The pinned platform has no caller for GradeEventContextRequested, so it requires an upstream/custom integration to fire. AccountSettingsRenderStarted and CourseEnrollmentQuerysetRequested likewise have no callers in stock Verawood; they remain registered for compatibility with custom integrations.

See the Verawood compatibility and code review for the upstream comparison, fixed defects, and deployment validation limits.

Existing recent coverage retained from prior releases includes:

• Filter: AccountSettingsRenderStarted
• Signals:
  • EXTERNAL_GRADER_SCORE_SUBMITTED
  • LIBRARY_BLOCK_PUBLISHED
  • LIBRARY_CONTAINER_CREATED
  • LIBRARY_CONTAINER_UPDATED
  • LIBRARY_CONTAINER_DELETED
  • LIBRARY_CONTAINER_PUBLISHED
  • COURSE_IMPORT_COMPLETED

Adding More Filters

From version to version, new filters are added to Open edX. The complete list of filters and their definitions can be found in filters.py in the openedx-filters repository.

To add a new filter, create the filter class handler in filters.py containing the run_filter function. Then add a block in common.py linking the signal identifier with the function. run_filter must always return a dict, which can be empty.

Adding New Event Hooks

From version to version, new event producers are added to Open edX. The complete list of events and their definitions can be found in signals.py in different folders in the openedx-events repository, depending on their category.

To add a new event hook, add the signal to the signals dict in apps.py. Then add the corresponding block to receivers.py.

One-Time Setup

# Clone the repository
git clone git@github.com:aulasneo/openedx-webhooks.git
cd openedx-webhooks

# Set up a virtualenv with the same name as the repo and activate it
# Here's how you might do that if you have virtualenvwrapper setup.
mkvirtualenv -p python3.12 openedx-webhooks

Every Time You Develop Something In This Repo

# Activate the virtualenv
# Here's how you might do that if you're using virtualenvwrapper.
workon openedx-webhooks

# Grab the latest code
git checkout main
git pull

# Install/update the dev requirements
make requirements

# Run the tests and quality checks (to verify the status before you make any changes)
make validate

# Make a new branch for your changes
git checkout -b <your_github_username>/<short_description>

# Using your favorite editor, edit the code to make your change.
vim ...

# Run your new tests
pytest ./path/to/new/tests

# Run all the tests and quality checks
make validate

# Commit all your changes
git commit ...
git push

# Open a PR and ask for review.

Releasing

PyPI publishing uses GitHub Actions with PyPI trusted publishing. The release workflow no longer uses a long-lived PyPI API token. Configure the project's trusted publisher in PyPI before cutting a GitHub release.

Release automation expects tags in the format release/v<version>, for example release/v22.0.0. Pushing one of those tags from a commit contained in main creates a GitHub release, and the publish workflow can also be run manually from the Actions tab when needed.

Getting Help

If you need any help, email info@aulasneo.com.

More Help

If you're having trouble, there are discussion forums at https://discuss.openedx.org where you can connect with others in the community.

Real-time conversations are on Slack. You can request a Slack invitation, then join the community Slack workspace.

For anything non-trivial, the best path is to open an issue in this repository with as many details about the issue as possible:

https://github.com/aulasneo/openedx-webhooks/issues

For more information about these options, see the Getting Help page.

License

The code in this repository is licensed under the AGPL 3.0 unless otherwise noted.

See LICENSE.txt for details.

Contributing

Contributions are very welcome. If you want to contribute to this project, please feel free to open an issue.

Reporting Security Issues

Please do not report security issues in public. Email operations@aulasneo.com.