Backend

Helpdesk ticket API

A ticket-management backend with role permissions, searchable endpoints, and asynchronous escalation tasks.

Django REST Framework
Celery
Redis
OpenAPI

Overview

Keeping support requests from getting lost

A helpdesk needs more than a form for reporting a problem. People need to find their own requests, support agents need an assigned queue, and unresolved work needs a way to reach the right people.

This project is a ticket-management backend built around that workflow. It organises requests by status, priority, and assignee, with different responsibilities for requesters, agents, and administrators.

The aim is to connect everyday support operations with the backend decisions that make them possible: access control, searchable records, background work, and a clear API.

Follow a ticket through the system

An interactive illustration of the support workflow, using an example request.

A requester reports a problem and gives it a priority.

“I cannot sign in.” The new ticket is marked open, linked to its requester, and scheduled for follow-up if it remains unresolved.

Requesters can find their own tickets, agents work through assigned requests, and administrators see the full queue. An unresolved ticket can be escalated; a resolved or closed ticket is left alone.

Technical detail

Request handling and access

The application uses Django REST Framework for ticket creation, retrieval, filtering, and updates. Role-specific querysets distinguish a requester’s own tickets, an agent’s assigned tickets, and the administrator’s broader view.

Models, serializers, views, and permission classes keep persistence, representation, and access rules separate. OpenAPI documentation makes the API’s request shapes discoverable to other developers.

Authenticated request
Role and object access
Ticket persistence
Redis task broker
Celery escalation + email

Background escalation

An unresolved ticket should not require someone to watch a queue continuously. Celery handles delayed escalation through Redis, keeping that work outside the HTTP request. The task checks the ticket’s current status before marking it escalated and sending an email; resolved and closed tickets are left alone.

An important boundary is the transition between saving a ticket and scheduling work against it. Scheduling after the database transaction completes keeps the worker from receiving an identifier before its record is available.

What this project demonstrates

The project brings together relational modelling, role-based permissions, asynchronous processing, and API design. It is a backend prototype; the interactive walkthrough illustrates the intended workflow using example data rather than connecting to a hosted helpdesk.