Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/0m1n3m/contacts-db/llms.txt

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

Contacts DB exposes its full feature set through standard Laravel web routes and a focused set of JSON API routes. Every route — whether it returns an HTML view or a JSON payload — requires an active authenticated session. There is no stateless token-based API; all access flows through Laravel Breeze session cookies.

​
Authentication

All routes sit behind the auth and verified middleware — both session authentication and email verification are required everywhere, including the /api/* prefix routes. Authentication is established by posting credentials to the Laravel Breeze login endpoint, which sets a session cookie that must accompany every subsequent request. 
POST /login
Content-Type: application/x-www-form-urlencoded

email=admin@example.com&password=secret&_token=CSRF_TOKEN
A successful login responds with a 302 redirect and sets the laravel_session cookie. Include that cookie in all subsequent requests.
There is no Bearer token or API key authentication. All integrations must use the session cookie obtained from POST /login.

​
CSRF Protection

Laravel enforces CSRF verification on all POST, PATCH, and DELETE requests. You must supply the token in one of two ways:
  • Header: X-XSRF-TOKEN: <token> — use the value from the XSRF-TOKEN cookie that Laravel sets automatically
  • Form field: include _token=<token> as a hidden input or form body parameter
Requests that omit the CSRF token receive a 419 Page Expired response.

​
Response Formats

The application uses two distinct response styles depending on the route group:
Route typeResponse
Web routes (/contacts, /tasks, /projects, etc.)HTML Blade views or 302 redirects after mutations
JSON API routes (/api/*)JSON payloads
PATCH /tasks/{task}/change-status{"success": true} on success, {"error": "…"} on failure
PATCH /tasks/{task}/move{"ok": true} on success, {"message": "…"} on failure
After a successful form submission (create, update, delete), web routes redirect back to the relevant index or detail page and flash a status or success message to the session.

​
HTTP Status Codes

​
200
OK
Successful read or JSON API operation.
​
302
Found
Redirect after a successful form submission (create, update, delete, import, export).
​
400
Bad Request
General failure — used by the Kanban status-change endpoint when an unexpected exception occurs.
​
403
Forbidden
The authenticated user lacks the required role or policy permission for the requested operation.
​
404
Not Found
The requested resource does not exist or is not accessible to the current user.
​
422
Unprocessable Entity
Validation failure — returned by JSON API routes and dependency endpoints when input is invalid.

​
Route Groups

The table below summarises every protected route group in the application. All groups require both session authentication (auth) and email verification (verified).
PrefixMiddlewareDescription
/contactsauth + verifiedContact CRUD and CSV import/export
/tasksauth + verifiedTask CRUD and Kanban board
/projectsauth + verifiedProject CRUD
/api/tagsauth + verifiedTags JSON API
/api/tasks/{task}/tagsauth + verifiedTask tag attachment JSON API
/api/tasks/{task}/dependenciesauth + verifiedTask dependency JSON API
/notificationsauth + verifiedNotification inbox and mark-read web routes
/api/notifications/recentauth + verifiedNotification dropdown JSON API
/adminauth + verified + role:adminAdmin-only routes (invitations)
Editors can create and modify most resources but cannot delete contacts, bulk-delete contacts, or delete tags. Viewers have read-only access and can only see tasks they are assigned to.

​
Endpoint Reference

Build docs developers (and LLMs) love

Get started for freeTalk to us