Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Edfermachado/proyectoSistemas/llms.txt

Use this file to discover all available pages before exploring further.

Every approved event in UniEvents has a dedicated attendees list that faculty admins can access to track registrations, monitor payment status, and manually add participants. For paid events, the portal includes a payment verification workflow that lets tenant_admin users approve or reject payment proofs submitted by attendees.

​
Viewing Attendees

Navigate to /faculty-admin/events/[id]/attendees to see all registrations for a specific event. The attendees page can be reached from the events table by clicking the Ver Asistentes button, which is only visible for events with status = 'aprobado'. The attendees table displays the following columns:
ColumnDescription
NameFull name of the attendee.
EmailContact email address.
PhoneContact phone number.
Registration DateTimestamp of when the attendee registered.
StatusCurrent registration status (registrado, confirmado, or pago_pendiente).
Payment Reference(Paid events only) The reference code submitted by the attendee.
Screenshot(Paid events only) Link to the uploaded payment screenshot stored in Supabase.
A summary strip at the top of the page shows real-time counts for:
  • Total registered — all attendees regardless of status.
  • Confirmed — attendees with status = 'confirmado'.
  • Pending payment — attendees with status = 'pago_pendiente'.
  • Space capacity — the physical capacity of the assigned venue.
Use the stats strip to quickly gauge how many payment verifications are pending before an event starts. High pago_pendiente counts right before an event may indicate a surge in late registrations that need review.

​
Attendee Statuses

The registration_status enum defines three possible states for an attendee record:
StatusWhen it applies
registradoThe attendee has signed up but no payment has been submitted (or their payment was rejected and cleared).
pago_pendienteThe attendee has submitted a payment reference and screenshot, awaiting admin verification.
confirmadoThe attendee’s registration is fully confirmed — either through payment verification, or because the event is free (free-event registrations are automatically confirmed upon registration).
The initial status is determined automatically by AttendeesService.registerAttendee:
  • Free events (price = '0', 'FREE', or 'GRATIS') → confirmado
  • Paid events (any other price) → pago_pendiente (when submitted with a payment reference) or registrado (no payment yet)

​
Payment Verification

For paid events, attendees submit a payment reference number and a screenshot of their mobile payment as proof. Their status becomes pago_pendiente. A tenant_admin then reviews the proof and takes one of two actions: Approve a payment: 
POST /api/payments/verify
Content-Type: application/json
Cookie: session=<tenant-admin-jwt>

{
  "attendeeId": "att-uuid",
  "action": "approve"
}
  • Sets status → 'confirmado'
  • Records paymentVerifiedBy (the admin’s user ID) and paymentVerifiedAt (current timestamp)
Reject a payment: 
POST /api/payments/verify
Content-Type: application/json
Cookie: session=<tenant-admin-jwt>

{
  "attendeeId": "att-uuid",
  "action": "reject"
}
  • Sets status → 'registrado'
  • Clears paymentReference and paymentScreenshotUrl, allowing the attendee to resubmit
Success response (both actions): 
{
  "success": true
}
Only users with the tenant_admin role can call POST /api/payments/verify. Requests from event_manager or access_control sessions will receive a 401 Unauthorized response. Cross-tenant verification attempts (where the attendee’s event belongs to a different faculty) return 403 Forbidden.

​
Manual Registration

Faculty admins can register attendees directly without requiring them to go through the public registration flow. The ManualRegisterForm component is embedded at the top of the attendees page and accepts the attendee’s name, email, phone, and type. Manually registered attendees are created with status = 'confirmado' by default, bypassing the payment verification step regardless of the event’s pricing. This is useful for:
  • Adding VIP guests or invited speakers.
  • Registering attendees who paid in person.
  • Correcting registrations that were missed in the system.

Build docs developers (and LLMs) love

Get started for freeTalk to us