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.

Build docs developers (and LLMs) love

Get started for freeTalk to us