Skip to main content
The Tickets API provides a comprehensive issue tracking system for community residents. Residents can create tickets to report issues, request services, or communicate concerns. Administrators can track, categorize, and resolve these tickets efficiently.

​
Key Features

  • Ticket Management: Create, update, and track support tickets
  • Categorization: Organize tickets by predefined categories (maintenance, security, amenities, etc.)
  • Status Tracking: Monitor ticket lifecycle from creation to resolution
  • Comments System: Add threaded comments to tickets for communication
  • Image Attachments: Attach images to tickets and comments for better documentation
  • Role-Based Access: Different permissions for residents and administrators

​
Core Resources

​
Tickets

The main ticket resource represents an issue or request from a community resident. Each ticket includes:
  • Category classification (CategoriaTicketId)
  • Current status (StatusId)
  • Reporting date (FechaReporte)
  • Description and content (Contenido, max 4,000 characters)
  • Optional image attachments (ImageUrls array)
  • Links to community and resident
  • Audit timestamps (CreatedAt, UpdatedAt)

​
Categories

Predefined categories help organize tickets by type:
  • Common areas (Areas comunes)
  • Amenities
  • Maintenance (Mantenimiento)
  • Security concerns
  • Administrative requests
  • Other classifications
Categories are managed through the /api/categoriaticket endpoints.

​
Statuses

Ticket statuses track the resolution lifecycle:
  • Nuevo (New): Newly created ticket
  • En revisión (Under Review): Being reviewed by staff
  • En investigación (Under Investigation): Under investigation
  • En proceso (In Progress): Work in progress
  • Cancelado (Cancelled): Cancelled ticket
  • Resuelto (Resolved): Issue resolved
Each status includes:
  • Code-based status identification
  • Descriptive labels (Descripcion)
  • Color coding for UI display (hex color values)

​
Comments

Comments enable communication on tickets:
  • Threaded discussions via IdComment (replies to comments)
  • Multi-origin support (tickets, events, posts, providers, etc.)
  • Image attachments
  • Resident attribution
  • Text content (ComentarioTexto, max 4,000 characters)
Comments are managed through the /api/comentarios endpoints and use an origin-based system where origen = “ticket” and idOrigen = ticket ID.

​
Common Workflows

​
Resident Creating a Ticket

  1. Resident authenticates and gets their profile
  2. Resident retrieves available categories via GET /api/categoriaticket
  3. Resident creates ticket with POST /api/tickets specifying:
    • CategoriaTicketId (required)
    • Contenido (optional description)
    • Images handled separately (paths stored in ImageUrls)
  4. System automatically assigns ResidentId from authenticated user
  5. System assigns initial status
  6. Resident can view their tickets via GET /api/tickets/my

​
Administrator Managing Tickets

  1. Administrator views all tickets via GET /api/tickets or by community via GET /api/tickets/community/{communityId}
  2. Administrator filters and reviews tickets
  3. Administrator updates ticket status via PUT /api/tickets/{id} with new StatusId
  4. Administrator adds comments for updates via POST /api/comentarios
  5. Administrator resolves ticket by setting appropriate status

​
Adding Comments

  1. User views ticket details via GET /api/tickets/{id}
  2. User retrieves existing comments via GET /api/comentarios/origen/ticket/{ticketId}
  3. User creates comment via POST /api/comentarios with:
    • origen: “ticket”
    • idOrigen: ticket ID as string
    • comentarioTexto: comment text
    • idComment: parent comment ID for replies (optional)
  4. Other users can reply to comment by setting idComment (threaded discussion)

​
Admin Creating Ticket on Behalf of Resident

  1. Admin authenticates with ADMIN_COMPANY or SYSTEM_ADMIN role
  2. Admin creates ticket via POST /api/tickets specifying:
    • CategoriaTicketId (required)
    • Contenido (optional)
    • ResidentId (optional): specific resident
    • CommunityId (optional): if ResidentId not provided, uses first resident from community
  3. Either ResidentId or CommunityId must be provided for admin creation

​
Authorization

All ticket endpoints require authentication. Authorization levels vary:

​
Tickets Endpoints

  • GET /api/tickets: ADMIN_COMPANY, SYSTEM_ADMIN only
  • GET /api/tickets/community/: ADMIN_COMPANY, SYSTEM_ADMIN only
  • GET /api/tickets/my: Any authenticated user (returns their tickets)
  • GET /api/tickets/: Any authenticated user
  • POST /api/tickets: Any authenticated user (residents create for self, admins can specify resident)
  • PUT /api/tickets/: Owner or admins (residents can only update their own tickets)
  • DELETE /api/tickets/: Any authenticated user

​
Categories & Statuses

  • All authenticated users can read categories and statuses

​
Comments

  • Any authenticated resident can create and manage comments on tickets they can access

​
Data Limits

  • Ticket content: Maximum 4,000 characters
  • Comment text: Maximum 4,000 characters
  • Request size: 1 MB limit for JSON payloads
  • Images: Stored as relative URL paths (e.g., “uploads/tickets/1/photo.jpg”)
  • Origen field: Maximum 50 characters
  • IdOrigen field: Maximum 50 characters

​
Next Steps

Explore the Tickets Endpoints documentation for detailed information about each API endpoint, including request parameters, request bodies, and response examples.