Documentation Index
Fetch the complete documentation index at: https://mintlify.com/ericcobasdev/careertrack-api/llms.txt
Use this file to discover all available pages before exploring further.
CareerTrack’s persistence layer is built on two primary tables: users and job_applications. The users table stores authenticated account information managed by Laravel’s built-in auth scaffolding, while job_applications stores every application record and references back to the owning user via a foreign key. A third table — personal_access_tokens — is managed entirely by Laravel Sanctum and stores the API tokens used for authentication.
Users table
The users table is created by the default Laravel migration and extended with the HasApiTokens trait from Sanctum to support token-based authentication.
| Column | Type | Nullable | Description |
|---|
id | bigint (unsigned) | No | Auto-incrementing primary key. |
name | varchar(255) | No | The user’s display name. |
email | varchar(255) | No | Unique email address used for login. |
email_verified_at | timestamp | Yes | Set when the user verifies their email; null if unverified. |
password | varchar(255) | No | Bcrypt-hashed password. Never returned by the API. |
remember_token | varchar(100) | Yes | Laravel’s standard remember-me token. Never returned by the API. |
created_at | timestamp | Yes | Timestamp of account creation. |
updated_at | timestamp | Yes | Timestamp of last account update. |
User model marks password and remember_token as hidden, so they are never included in serialised output or API responses.
Job applications table
The job_applications table is created by the 2026_04_05_124911_create_job_applications_table migration. Every column maps directly to a field exposed by the API.
| Column | Type | Nullable | Default | Description |
|---|
id | bigint (unsigned) | No | auto-increment | Primary key. |
user_id | bigint (unsigned) | No | — | Foreign key → users.id. Cascades on delete. |
company_name | varchar(255) | No | — | Name of the company. |
position_title | varchar(255) | No | — | Title of the role applied for. |
status | varchar(255) | No | 'applied' | Current lifecycle stage. Constrained to enum values at the application layer. |
source | varchar(255) | Yes | null | Where the listing was found (e.g. LinkedIn, Indeed). |
source_url | varchar(255) | Yes | null | Direct URL to the job posting. |
salary_min | int | Yes | null | Lower bound of the expected salary range. |
salary_max | int | Yes | null | Upper bound of the expected salary range. |
location | varchar(255) | Yes | null | Role location (e.g. Remote, New York, NY). |
notes | text | Yes | null | Free-form notes about the application. |
applied_at | date | Yes | null | The date the application was submitted. |
next_step_at | timestamp | Yes | null | Datetime of the next scheduled step (interview, deadline, etc.). |
created_at | timestamp | Yes | null | Auto-managed record creation timestamp. |
updated_at | timestamp | Yes | null | Auto-managed last-modified timestamp. |
Relationships
The two tables share a straightforward one-to-many relationship:
- A User has many JobApplications — expressed in the
User model as hasMany(JobApplication::class).
- A JobApplication belongs to one User — expressed in the
JobApplication model as belongsTo(User::class).
- The foreign key
job_applications.user_id references users.id and is configured with cascadeOnDelete: when a user account is deleted, all of their job applications are deleted automatically.
users job_applications
───────────────────── ─────────────────────────────
id ◄──────────── user_id (FK, cascade delete)
name id
email company_name
email_verified_at position_title
password status
remember_token source
created_at source_url
updated_at salary_min
salary_max
location
notes
applied_at
next_step_at
created_at
updated_at
Model casts
The JobApplication model defines three explicit casts that transform raw database values into richer PHP types on read, and back to their storage format on write:
| Property | Cast | Behaviour |
|---|
status | ApplicationStatus::class | Deserialises the stored string into an ApplicationStatus enum instance. The API serialises it back to its string value in responses. |
applied_at | 'date' | Parsed as a Carbon date object (no time component). The API formats it as YYYY-MM-DD in responses. |
next_step_at | 'datetime' | Parsed as a full Carbon datetime. The API formats it as an ISO 8601 string (e.g. 2026-04-10T14:00:00.000000Z) in responses. |
protected $casts = [
'status' => ApplicationStatus::class,
'applied_at' => 'date',
'next_step_at' => 'datetime',
];
Personal access tokens
Laravel Sanctum creates and manages a personal_access_tokens table to store the API bearer tokens issued during login. CareerTrack does not expose this table through the API — it is an internal implementation detail. The User model includes the HasApiTokens trait to wire up token creation and revocation. Every request to a protected endpoint must present a valid token in the Authorization: Bearer <token> header; Sanctum resolves the authenticated user from that token before any controller logic runs.
For local development, CareerTrack works out of the box with SQLite. SQLite requires no separate database server process — just set DB_CONNECTION=sqlite in your .env file and run php artisan migrate. The database is stored as a single file (database/database.sqlite) that you can delete and recreate at any time.