Context

I've cleaned up the secret sharing API and added identity support. I haven't done much work on the requests side of things. If we expose the secret requests router, we can clean that one up more as well. The requests router is in much better shape than the secret sharing router was prior to this PR though.

Secret Sharing API - Before & After

Route Changes

Behavioral Changes

GET /api/v1/secret-sharing/:id (New)

• Returns full secret metadata (without secret value)
• Auth logic: No auth for accessType: "anyone", requires auth + org check for accessType: "organization"
• Enables frontend to determine if password prompt is needed before attempting access

POST /:id/access

• Renamed from POST /public/:id for clarity (it's an action, not a resource read)
• Removed brandingConfig from response (now fetched separately via GET /branding?sharedSecretId=...)
• Removed error field from response (errors now use proper HTTP status codes)

Response Schema Changes

Before (POST /public/:id):

{
  isPasswordProtected: boolean;
  secret?: {
    secretValue?: string;
    // other fields
  };
  brandingConfig?: {}; // now removed
  error?: string;           // now removed
}

After (GET /:id):

{
  id: string;
  name: string | null;
  accessType: "organization" | "anyone";
  expiresAt: string;
  expiresAfterViews: number | null;
  isPasswordProtected: boolean;
  // ... full sanitized secret (no secret value)
}

After (POST /:id/access) - new endpoint:

{
  id: string;
  name: string | null;
  accessType: "organization" | "anyone";
  expiresAt: string;
  secretValue?: string;      // The actual secret
  orgName?: string;
  // ... full sanitized secret
}

Frontend Flow Change

Before:

1. POST /public/:id: Returns everything in one call (metadata + secret value + branding). Would be called multiple times in the frontend for password protected secrets.
   After:
2. GET /:id: Get metadata (is it password protected? what access type?)
3. If not password protected: automatically call POST /:id/access
4. If password protected: show password prompt, then call POST /:id/access with password
5. GET /branding?sharedSecretId=..., fetch branding separately

Breaking changes

In the past, secret sharing was end-to-end encrypted. We used to look up secrets using a combination of the secret's UUIDv4 ID and a hashed hex. This is over 14 months old, and I've now removed this logic from the API. This means that shared secrets that are over 14 months old will no longer work. This is not a problem, as secrets are set to expire at the latest after 30 days.

Steps to verify the change

Type

• Fix
• Feature
• Improvement
• Breaking
• Docs
• Chore

Checklist

• Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
• Tested locally
• Updated docs (if needed)
• Read the contributing guide