Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/paramveer-cyber/Deployaar/llms.txt

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

Deployaar authenticates all API requests using better-auth with session cookies backed by a Drizzle-connected Postgres database. The apps/web Next.js application sends cookies automatically on every request — no extra configuration is needed. External REST API consumers must first obtain a session cookie by signing in through one of the supported authentication methods, then pass that cookie along with subsequent requests.
The @repo/trpc/client used by the web application handles authentication transparently. The steps on this page are aimed primarily at external REST API consumers who need to authenticate programmatically.
Deployaar does not support API keys or bearer tokens. Session cookies are the only supported authentication mechanism. All unauthenticated requests to protected procedures receive a 401 UNAUTHORIZED response.

​
Authentication Methods

MethodEndpoint
Email / PasswordPOST /api/auth/sign-in/email
Google OAuthRedirect to GET /api/auth/sign-in/google
GitHub OAuthRedirect to GET /api/auth/sign-in/github

​
Sign In with Email / Password

Send a POST request with your credentials. Use the -c flag (or your HTTP client’s cookie-jar equivalent) to persist the returned session cookie for follow-up requests. 
curl -X POST https://deployaar.onrender.com/api/auth/sign-in/email \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com", "password": "your-password"}' \
  -c cookies.txt
The -c cookies.txt flag tells curl to save all cookies from the response — including the better-auth.session_token — to a local file. Subsequent requests can then replay those cookies automatically. Once you have saved the session cookie, pass it back on every subsequent request using the -b flag: 
curl https://deployaar.onrender.com/api/auth/get-session \
  -b cookies.txt
Any protected endpoint under /api/* or /trpc/* will accept the session cookie in the same way.

​
Get Current Session

GET /api/auth/get-session returns a JSON object representing the currently authenticated user and their active session. If no valid session cookie is present, the response body is null. 
curl https://deployaar.onrender.com/api/auth/get-session \
  -b cookies.txt
A successful response looks similar to: 
{
  "user": {
    "id": "usr_...",
    "email": "user@example.com",
    "name": "Jane Doe"
  },
  "session": {
    "id": "ses_...",
    "expiresAt": "2026-07-30T00:00:00.000Z"
  }
}

​
Sign Out

POST /api/auth/sign-out invalidates the current session on the server and clears the session cookie. After signing out, any further requests using the same cookie will receive a 401 UNAUTHORIZED response from protected procedures. 
curl -X POST https://deployaar.onrender.com/api/auth/sign-out \
  -b cookies.txt \
  -c cookies.txt

​
OAuth Flow (for External Clients)

OAuth flows for Google and GitHub require a browser redirect sequence that cannot be completed with a headless HTTP client alone:
1

Initiate the redirect

Navigate a browser to https://deployaar.onrender.com/api/auth/sign-in/google (or /github). better-auth stores OAuth state in the verification table and redirects to the provider’s consent screen.
2

Authorize on the provider

The user approves the OAuth grant on Google or GitHub’s consent screen.
3

Callback and session creation

The provider redirects back to /api/auth/callback/google (or /github). better-auth verifies the state parameter, creates a session, and sets the session cookie.
Because this flow requires an interactive browser, OAuth is best initiated from the Deployaar web UI. For programmatic or scripted external access, email/password sign-in is the recommended approach.

​
Authorization in tRPC

Deployaar’s tRPC layer enforces authorization at two levels: Session validation (protectedProcedure) Every sensitive tRPC procedure is defined using protectedProcedure, which runs the authMiddleware before the procedure handler executes. The middleware calls auth.api.getSession() with the incoming request headers. If no valid session is found, it throws a TRPCError with code UNAUTHORIZED: 
const authMiddleware = tRPCContext.middleware(async ({ ctx, next }) => {
  const session = await auth.api.getSession({ headers: ctx.req.headers as HeadersInit });

  if (!session?.user) {
    throw new TRPCError({ code: "UNAUTHORIZED" });
  }

  return next({
    ctx: {
      ...ctx,
      authenticatedUser: session.user,
    },
  });
});

export const protectedProcedure = tRPCContext.procedure.use(authMiddleware);
Organization-level authorization (canManageOrg) Procedures that modify organization resources additionally call canManageOrg(userId, orgId), which verifies the authenticated user holds the required role within the organization. Insufficient permissions result in a TRPCError with code FORBIDDEN. The tRPC context is constructed in packages/trpc/server/context.ts by forwarding the raw HTTP request headers — including the Cookie header — into the context object, making them available to auth.api.getSession() in every procedure.

​
CORS

The API configures CORS to allow credentials (credentials: true) exclusively from the origin specified by the FRONTEND_URL environment variable (set to the deployed web app’s URL at startup). Cross-origin requests from any other origin are rejected by the browser’s CORS preflight mechanism before they reach any route handler. 
Allowed origin: process.env.FRONTEND_URL  (e.g. https://deployaar.paramveer.xyz)
Credentials:    true
If you are building a local integration against a locally running API instance, ensure your FRONTEND_URL is set to http://localhost:3000 (or whichever origin your client runs on).

Build docs developers (and LLMs) love

Get started for freeTalk to us