What Is the Purpose of the apps/api Directory in Plane? Understanding the Backend Architecture

The apps/api directory houses the complete backend API layer for Plane, functioning as a self-contained Django project that exposes REST endpoints, handles background tasks, renders email templates, and provides shared utilities for the entire application.

The apps/api directory serves as the service-oriented backbone of the makeplane/plane repository. This monorepo structure isolates the server-side logic into a dedicated workspace, enabling independent builds, testing, and deployment of the backend while maintaining a clean separation from the web frontend and mobile clients.

Core Responsibility: The Django-Based Backend Layer

At its heart, apps/api is a full Django project that exposes Plane’s data models and business logic through a structured REST API.

REST API Endpoint Routing

The top-level URL configuration lives in [plane/urls.py](https://github.com/makeplane/plane/blob/preview/apps/api/plane/urls.py), which acts as the central router for all incoming HTTP traffic. This file mounts several sub-routers under specific namespaces:

• api/ → Internal application routes (plane.app.urls)
• api/public/ → Public workspace routes (plane.space.urls)
• api/instances/ → License handling endpoints (plane.license.urls)
• api/v1/ → Versioned REST API (plane.api.urls)
• auth/ → Authentication flows (plane.authentication.urls)

When the ENABLE_DRF_SPECTACULAR setting is true, the directory also serves an OpenAPI schema via DRF Spectacular views at /api/schema/, /swagger-ui/, and /redoc/.

OpenAPI Schema Generation

If ENABLE_DRF_SPECTACULAR is enabled in your configuration, the API automatically exposes interactive documentation endpoints. You can retrieve the raw schema using:

curl https://your-plane-instance.com/api/schema/ > openapi.json

Supporting Services and Infrastructure

Beyond routing HTTP requests, apps/api handles auxiliary concerns like health monitoring, email rendering, and asynchronous job processing.

Health Checks and Utility Endpoints

Simple utility views are implemented in [plane/web/views.py](https://github.com/makeplane/plane/blob/preview/apps/api/plane/web/views.py). The health_check function provides a lightweight endpoint for load balancers and monitoring systems:

def health_check(request):
    return JsonResponse({"status": "OK"})

Verify the service status with:

curl -s https://your-plane-instance.com/health/ | jq .

# Expected output: {"status": "OK"}

Email Template Rendering

All transactional email HTML files—including user activation, password reset, and workspace invitations—live under apps/api/templates/emails/. The backend renders these templates server-side when sending notifications to users, ensuring consistent branding across all communication channels.

Asynchronous Background Tasks

Long-running operations are offloaded to workers via Django’s background-task system. Task definitions reside in plane/bgtasks/, with implementations like [workspace_seed_task.py](https://github.com/makeplane/plane/blob/preview/apps/api/plane/bgtasks/workspace_seed_task.py) initializing newly created workspaces with default data:

from plane.bgtasks.workspace_seed_task import workspace_seed_task

# Enqueue the task for workspace ID 42

workspace_seed_task.delay(workspace_id=42)

Shared Utilities and Helpers

The plane/utils/ directory contains a rich ecosystem of helper modules that support the entire API layer:

• OpenAPI helpers (utils/openapi/) for schema generation and documentation
• Exporters (utils/exporters/) to produce CSV and JSON data exports
• Permission classes (utils/permissions/) enforcing fine-grained access control
• Logging, URL handling, and timezone conversion utilities

These modules ensure consistent behavior across all endpoints and background tasks.

Independent Build and Test Configuration

The apps/api directory contains its own pyproject.toml, requirements.txt, and run_tests.py script. This self-contained structure allows the backend to be built, linted, and tested independently from the rest of the monorepo, supporting containerized deployments and CI/CD pipelines that target only the API layer.

Summary

• apps/api is the service-oriented Django backend that powers all Plane clients and integrations.
• [plane/urls.py](https://github.com/makeplane/plane/blob/preview/apps/api/plane/urls.py) defines the routing structure for internal APIs, public endpoints, authentication, and versioning.
• Background tasks in plane/bgtasks/ handle asynchronous operations like workspace seeding and email delivery.
• Email templates are stored in templates/emails/ and rendered server-side for all transactional communications.
• The directory operates as an independent build unit with its own dependencies and test scripts.

Frequently Asked Questions

What framework powers the apps/api directory in Plane?

The apps/api directory is built on Django and Django REST Framework (DRF). This stack provides the ORM, request handling, serialization, and authentication mechanisms required for Plane’s REST API.

How does the Plane API handle background tasks?

Plane uses Django’s background-task system to queue asynchronous jobs. Tasks are defined in plane/bgtasks/ and executed by worker processes. For example, [workspace_seed_task.py](https://github.com/makeplane/plane/blob/preview/apps/api/plane/bgtasks/workspace_seed_task.py) initializes new workspaces with default projects and data without blocking the HTTP response.

Where are the email templates stored in Plane's API?

All transactional email templates are stored in apps/api/templates/emails/. These HTML files are rendered by Django’s templating engine when the API sends activation links, password resets, or workspace invitations to users.

Is apps/api in Plane a standalone service?

Yes, apps/api is designed as a self-contained service within the monorepo. It includes its own dependency management (pyproject.toml, requirements.txt) and testing infrastructure (run_tests.py), allowing it to be containerized and deployed independently from Plane’s web frontend.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}