CRM & Ticketing System
Reusable, containerized backend for CRM and ticket workflows.
GitHub · Live Demo · Back to Projects
- Problem: Demonstrate a reusable CRM/ticket backend with realistic access patterns and clean API boundaries.
- Approach: FastAPI service with RBAC tokens, Pydantic schemas, and containerized deployment.
- Outcome: One backend image reused across UI demos and “agent” clients without API changes.
A standalone CRM & Ticketing backend built with FastAPI and packaged as a reusable Docker image.
Designed with clean APIs, UI/API decoupling, and enterprise-style access patterns, making it suitable for both traditional UIs and LLM/agent integrations.
The API runs independently and can be consumed by web interfaces, agents, or other services without modification.
Key Capabilities:- FastAPI REST API for customers, tickets, and ticket notes.
- Token-based authentication with RBAC (Agent/Admin enforced at the API layer).
- Strict request/response schemas using Pydantic.
- Health/readiness endpoints for uptime checks and deployments.
- Dockerized deployment (reproducible local + portable demo).
Architecture
The backend is UI-agnostic and supports multiple clients, including web UIs and AI agents.
+-------------------+ HTTP +----------------------+
| UI / Agent | ─────────────▶ | CRM API Service |
| (Gradio, LLMs) | | (FastAPI, Docker) |
+-------------------+ +----------------------+
A Gradio UI is layered on top for demo purposes via Hugging Face Spaces. In production-style usage, the backend runs independently and is reused across clients.
Demo Deployment
- Docker demo is hosted in Hugging Face Spaces
- Gradio UI communicates with the API over an internal service URL
- Preconfigured tokens simulate enterprise access patterns
Engineering Notes
- API: FastAPI + Pydantic schemas
- Auth: token auth + RBAC
- Ops: health/readiness endpoints
- Deploy: Docker image portability
- Clients: UI-agnostic (UI/agents)
- Lesson: ARM vs amd64 debugging