Talocode rebrand and API-first foundation#37
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 700614a37f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const { project, uploads } = await getProjectOverview(projectId, userResult.userId); | ||
| if (!uploads.length) return NextResponse.json({ error: "At least one screenshot is required." }, { status: 400 }); | ||
|
|
||
| const { generationId } = await runGenerationForProject(project, uploads); |
There was a problem hiding this comment.
Return API errors instead of leaking generation exceptions
When an API client starts generation for a valid project but runGenerationForProject rejects—e.g. consumeGenerationCredit throws No credits remaining... or quality/rendering fails—this new v1 route lets the exception escape. The existing /api/generations/[projectId] route catches the same errors and maps exhausted credits to a 402 JSON response, but /api/v1/projects/:projectId/generate will return a generic 500/Next error response, making the documented API-first endpoint hard for clients to handle and hiding the billing action they need to take.
Useful? React with 👍 / 👎.
| export function getApiUserId(request: Request): string | null { | ||
| const headerUserId = request.headers.get("x-launchpix-user-id") ?? request.headers.get("x-user-id"); | ||
| if (!headerUserId) return null; | ||
| const userId = headerUserId.trim(); | ||
| if (!userId) return null; | ||
| return userId; |
There was a problem hiding this comment.
Bind API keys to a user instead of trusting the header
With SUPABASE_SERVICE_ROLE_KEY configured, these v1 routes use the admin Supabase client and bypass RLS, so the tenant boundary is entirely this caller-supplied x-launchpix-user-id value. In any environment where more than one API consumer has the shared LAUNCHPIX_API_KEY, a caller can put another user's UUID in this header and list/create/generate projects under that account; the API key needs to identify or be checked against the owner rather than accepting the owner UUID as proof of identity.
Useful? React with 👍 / 👎.
Talocode brand refresh, Render deployment config, and API-first developer endpoints.