Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Manuelfg1985/Proyecto_Final_26/llms.txt

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

The API manages applicant records — referred to as postulantes — stored in the postulantes collection in Firebase Firestore. Each record in that collection is modelled by the User class defined in src/models/Users.js, which handles field defaults, serialization to Firestore, and deserialization back to a JavaScript object.

​
Fields

Every applicant record is constructed from the following fields. Required fields must be supplied in the request body when creating or updating a record; optional fields fall back to the defaults shown.
On creation (POST), omit the id field from the request body entirely — Firestore generates the document ID automatically and it is never written as a document field. See Create Applicant for the full request schema.
​
id
string
The Firestore document ID. Auto-generated by Firestore on creation; null inside a User instance before the record is persisted. Populated via fromFirestore() when reading an existing document.
​
name
string
required
The applicant’s first name.
​
surname
string
required
The applicant’s last name.
​
email
string
required
The applicant’s email address.
​
birthdate
string
required
The applicant’s date of birth. Stored and returned as a plain string (e.g. "1990-05-15"); no automatic date parsing is applied to this field.
​
telephone
string
required
The applicant’s phone number (e.g. "+54 11 1234-5678").
​
city
string
required
The city where the applicant currently resides.
​
province
string
required
The province or state where the applicant currently resides.
​
applied_position
string
required
The job position the applicant has applied for.
​
application_date
Date
The date and time the application was submitted. Defaults to new Date() at construction time when not explicitly provided. Stored as a Firestore Timestamp and converted back to a JavaScript Date on read (see Firestore deserialization below).
​
status
string
The current status of the application. Defaults to "pending" when not provided. See Status values for the full list of recognised values.

​
Firestore serialization

When an applicant record is written to Firestore (e.g. via addDoc), the User instance calls toFirestore() to produce the plain object that is stored as the document body. The id field is intentionally excluded from this payload — Firestore manages document IDs independently and they must not be duplicated as a document field. 
toFirestore() {
  return {
    name: this.name,
    surname: this.surname,
    email: this.email,
    birthdate: this.birthdate,
    telephone: this.telephone,
    city: this.city,
    province: this.province,
    applied_position: this.applied_position,
    application_date: this.application_date,
    status: this.status
  };
}
The controller calls newUser.toFirestore() as the data argument to addDoc(collection(db, "postulantes"), ...), ensuring the document is always written in a consistent shape without the transient id property.

​
Firestore deserialization

When an applicant record is read back from Firestore, the static fromFirestore(doc) method reconstructs a User instance from a Firestore DocumentSnapshot. It handles two concerns that raw doc.data() does not:
  1. Document ID — doc.id is mapped to the id field so callers always have a single, unified object.
  2. Timestamp conversion — Firestore stores application_date as a Timestamp object. fromFirestore calls .toDate() on it to return a plain JavaScript Date, or null if the field is absent.
static fromFirestore(doc) {
  if (!doc.exists) return null;

  const data = doc.data();

  return new User({
    id: doc.id, // Recuperamos el ID del documento
    name: data.name,
    surname: data.surname,
    email: data.email,
    birthdate: data.birthdate,
    telephone: data.telephone,
    city: data.city,
    province: data.province,
    applied_position: data.applied_position,
    application_date: data.application_date ? data.application_date.toDate() : null,
    status: data.status
  });
}
fromFirestore returns null when doc.exists is false, so callers should always guard against a null return value before accessing fields on the result.

​
Example document

The following JSON represents a complete applicant record as returned by the API after Firestore deserialization (e.g. from GET /applicants/:id): 
{
  "id": "abc123",
  "name": "María",
  "surname": "González",
  "email": "[email protected]",
  "birthdate": "1990-05-15",
  "telephone": "+54 11 1234-5678",
  "city": "Buenos Aires",
  "province": "Buenos Aires",
  "applied_position": "Frontend Developer",
  "application_date": "2024-01-15T10:30:00.000Z",
  "status": "pending"
}

​
Status values

The status field is a free-form string in the data model — no server-side enum validation is enforced. The following values represent the conventional workflow stages used across the API:
Because status accepts any string, your integration can introduce additional workflow states (e.g. "interview_scheduled") without schema changes. Document custom values in your own integration guide to keep team usage consistent.

Build docs developers (and LLMs) love

Get started for freeTalk to us