Public entry points

This page documents the first-touch API surfaces: public auth flows, landing-page conversion endpoints, and lightweight self-service auth operations.

Public auth flows

These routes do not require an access token.

Endpoint	Purpose	Current response shape
POST /api/v1/auth/login	Email/password login	raw AuthResponse
POST /api/v1/auth/register	Account creation	raw AuthResponse
POST /api/v1/auth/refresh	Refresh access token using refresh token	raw AuthResponse
POST /api/v1/auth/google	Google sign-in	raw AuthResponse
POST /api/v1/auth/logout	Revoke refresh token	empty 200 response
POST /api/v1/auth/reset-password-request	Request reset email with JSON body	raw success string
POST /api/v1/auth/forgot-password?email=...	Request reset email with query param	raw success string
POST /api/v1/auth/reset-password	Reset password from token	raw success string
GET /api/v1/auth/reset-password/validate?token=...	Validate reset token	raw boolean
POST /api/v1/auth/verify-email	Verify email with JSON body	raw success string
GET /api/v1/auth/verify-email?token=...	Verify email with query param	raw success string
GET /api/v1/auth/verify-email/validate?token=...	Validate verification token	raw boolean
POST /api/v1/auth/resend-verification?email=...	Re-send verification email	raw success string

Notable contract details:

• logout is driven by the refresh token in the request body, not by the access token alone.
• Password reset and email verification currently expose both JSON-body and query-param variants.
• These auth routes do not consistently use the backend ApiResponse<T> envelope.

Public landing and conversion endpoints

These routes are public but are not part of the auth domain.

Endpoint	Purpose	Current response shape
POST /api/v1/screener	Lightweight SR&ED quick pre-check from the marketing site	ApiResponse<QuickPrecheckResponse>
POST /api/v1/contact/submit	Contact form submission and email notification	plain { success, message } object
GET /api/v1/subscription-plans	Public pricing catalog and expert review offer	ApiResponse<SubscriptionPlansResponse>

Screener-specific behavior:

• the request body is a minimal { "input": "..." }
• the backend creates synthetic project/session IDs for the Python envelope
• the request is intentionally not persisted into the main project/session model

Contact-form-specific behavior:

• the endpoint is IP-rate-limited
• application failures return 400 with success: false
• the response is a plain map, not the shared envelope

Authenticated self-service auth endpoints

These routes require a bearer token, but they still behave like entrypoint APIs because they manage the user session itself.

Endpoint	Purpose	Current response shape
GET /api/v1/auth/me	Read current user profile	raw UserDTO
PATCH /api/v1/auth/me	Update current user profile	raw UserDTO
POST /api/v1/auth/email-verification	Send verification email for current user	raw success string
POST /api/v1/auth/change-password	Change password for current user	raw success string

For these routes, missing auth usually results in a plain 401 response rather than an ApiResponse<T> error envelope.

Response-shape caveat

The public edge of the system is not perfectly uniform today:

• some routes return raw DTOs such as AuthResponse or UserDTO
• some return raw booleans or strings
• some return the shared ApiResponse<T> envelope
• the contact form returns a plain success/error map

Treat this as the real contract for current integrations. If you are building a new caller, do not assume every first-touch endpoint can be handled by one generic envelope parser.

Related references

• Authentication
• Errors
• Billing and Stripe
• Internal boundaries