Support API keys

[stevesajeev1]

Description

Added (explicit) support for managing API keys:

• GET /apikeys/
  • List all API keys
• GET /apikeys/{apiKeyId}
  • Get specific API key
• POST /apikeys/
  • Create an API key
• DELETE /apikeys/{apiKeyId}
  • Delete an API key

Created a new route for authentication via an API key:

• POST /auth/sessions
  • Gets the API key through Bearer authentication, validates it, and creates a new session.

Schema

An API key has the following schema:

Column	Type	Nullable	Default	Description
id	uuid	No	gen_random_uuid()	Unique identifier for the API key
name	text	No	—	Human-readable name for the API key
description	text	Yes	—	Optional description of the API key
role	role	No	'visitor'	Role assigned to the API key
created_at	timestamptz	No	now()	Time the API key was created
expires_at	timestamptz	Yes	—	Optional expiration time
secret_hash	text	No	—	Hash of the API key secret; the plaintext secret is never stored

When an API key is created, a secret is generated, and its hash is stored in our database.

user_role was renamed to role to allow reuse for API keys.

Since sessions can now be created for either an API key or a user, the sessions table was modified to have user_id and api_key_id nullable columns (with the constraint that one of them has to be not null).

Type of Change

• New feature (non-breaking change)
• Refactor

Checklist

• My code follows the project's style guidelines
• I have commented on complex parts of the code
• [] I have updated documentation if necessary
• [] I have updated or added tests to cover my changes
• I have updated the OpenAPI YAML or other API schema files if applicable

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
core	Ready	Preview	Aug 13, 2026 2:47pm
xii-front-page	Error		Aug 13, 2026 2:47pm