The Skillara AI REST API does not use API keys or bearer tokens in the current implementation. Access control is enforced entirely through a CORS origin allowlist configured inDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/CristianParadaLopez/cv-builder/llms.txt
Use this file to discover all available pages before exploring further.
backend/src/index.ts. Any HTTP client that sends a valid Origin header matching the allowlist — or that sends no Origin header at all — can reach the API.
CORS allowlist
The following origins are permitted out of the box:| Origin | Environment |
|---|---|
http://localhost:5173 | Local Vite dev server |
http://localhost:3000 | Alternative local frontend port |
https://cv-builder-livid-two.vercel.app | Production Vercel deployment |
https://cv-builder-skillara.vercel.app | Production Vercel deployment (Skillara brand) |
Value of FRONTEND_URL env var | Self-hosted or staging environments |
FRONTEND_URL entry is filtered out if the variable is not set, so no empty-string origin is ever added to the list.
Configuring origins for self-hosted deployments
Set theFRONTEND_URL variable in your backend .env file to your frontend’s exact origin (scheme + host + optional port). Restart the backend after changing .env.
Origin header) are unaffected.
Calling the API without a browser
Direct API calls from tools such as Postman, curl, or any server-side HTTP client are permitted because those clients do not send anOrigin header, and the CORS middleware explicitly allows requests without an origin:
No token-based authentication
There are no bearer tokens, API keys, or session cookies required in the current build. The Skillara AI backend does not validate anAuthorization header for any endpoint. The Authorization header is listed in allowedHeaders to avoid CORS preflight failures from clients that may include it, but it is not read or verified by any middleware.
CV data persistence uses Firebase on the client side. The backend does not issue or validate JWTs.
The Prisma schema included in the repository defines a
User model with googleId and password fields, which suggests that token-based authentication is planned for a future release. Today, no such check is enforced at the API layer.