Skip to main content

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 returns consistent JSON error responses for every failure scenario — whether that is a missing required field, an expired token, or a resource that does not exist. All responses use the application/json content type, so clients never need to parse HTML error pages. This guide documents every status code the API uses, the exact response shapes, and the validation rules enforced on job application requests.

​
HTTP Status Codes

The following table covers every HTTP status code that CareerTrack endpoints can return:
Status CodeMeaningWhen It Occurs
200 OKSuccessSuccessful GET or PUT/PATCH request
201 CreatedResource createdSuccessful POST that creates a new resource
204 No ContentResource deletedSuccessful DELETE — response body is empty
401 UnauthorizedAuthentication requiredRequest is missing a token or the token is invalid/expired
403 ForbiddenAccess deniedThe authenticated user is not allowed to perform the action
404 Not FoundResource missingThe requested resource does not exist
422 Unprocessable EntityValidation failureOne or more request fields failed validation rules
500 Internal Server ErrorServer errorAn unexpected exception occurred on the server

​
Validation Errors (422)

When a request fails validation, Laravel returns a 422 Unprocessable Entity response. The body always contains a top-level message string (a human-readable summary of the first failure) and an errors object that maps each failing field name to an array of error strings. The following example shows the response when both company_name and position_title are omitted from a create application request: 
{
  "message": "The company name field is required.",
  "errors": {
    "company_name": ["The company name field is required."],
    "position_title": ["The position title field is required."]
  }
}
Only fields that actually fail validation appear in errors. Fields that pass are omitted from the object entirely.

​
Authentication Errors (401)

Requests to protected endpoints without a valid Sanctum bearer token receive a 401 Unauthorized response: 
{
  "message": "Unauthenticated."
}
To authenticate, include the token returned by POST /api/auth/login in the Authorization header of every subsequent request: 
Authorization: Bearer YOUR_TOKEN_HERE

​
Login Credential Errors

When a client calls POST /api/auth/login with an email or password that does not match any account, the API returns a 422 response with a field-level error on email: 
{
  "message": "The provided credentials are incorrect.",
  "errors": {
    "email": ["The provided credentials are incorrect."]
  }
}
Note that this response deliberately does not distinguish between “email not found” and “wrong password” to avoid leaking information about registered accounts.

​
Form Request Validation Rules

CareerTrack enforces input validation using two Laravel Form Request classes:
  • StoreJobApplicationRequest — applied to POST /api/applications
  • UpdateJobApplicationRequest — applied to PUT /api/applications/{id} and PATCH /api/applications/{id}
The table below documents every validated field, whether it is required, and the constraints applied:
FieldRequired on CreateRequired on UpdateRules
company_name✅ YesNo (optional)string, max 255 characters
position_title✅ YesNo (optional)string, max 255 characters
statusNoNoOne of: applied, interview, offer, rejected
sourceNoNostring, max 255 characters
source_urlNoNoValid URL, max 255 characters
salary_minNoNointeger, min value 0
salary_maxNoNointeger, min value 0
locationNoNostring, max 255 characters
notesNoNostring, no length limit
applied_atNoNoValid date (e.g., 2026-04-05)
next_step_atNoNoValid date
On update requests, fields are validated with sometimes — meaning the rule only runs if the field is present in the request body. You may send a partial payload and only the included fields will be validated and updated.
Use the errors object in the 422 response to drive field-level feedback in your client UI. Each key in errors maps directly to the request field that failed, and its value is an array of one or more human-readable messages you can display beside the relevant input. For example, errors.company_name[0] gives you the first error message for the company name field.

Build docs developers (and LLMs) love

Get started for freeTalk to us