Skip to main content
AnotherWrapper mostly uses App Router route handlers. Many “API features” are not in one central /api folder because app-specific routes live next to the app that owns them.

​
Two Main API Areas

​
Shared API routes

These live under:
  • app/api/*
Examples:
  • auth initiation
  • Google auth
  • avatar uploads
  • OG image generation
  • payment webhooks

​
App-specific API routes

These live inside the product apps themselves. Examples:
  • app/(apps)/chat/api/*
  • app/(apps)/image-studio/api/*
  • app/(apps)/video-studio/api/*
  • app/(apps)/voice/api/*
  • app/(apps)/audio/api/*
  • app/(apps)/vision/api/*
  • app/(apps)/structured-output/api/*
This keeps the logic close to the UI and product flow it belongs to.

​
Common Backend Patterns In This Repo

​
Auth-first route protection

Many routes use helpers such as requireApiUser() so protected actions fail fast if the user is not logged in.

​
Credit reservation and refund

AI generation routes often follow this pattern:
  1. authenticate the user
  2. reserve credits
  3. call the provider
  4. store the result
  5. refund credits if the generation fails
That pattern shows up in several AI app routes.

​
Provider abstraction

The backend usually does not hardcode one provider flow per page. Instead, it routes through shared model/provider helpers where possible.

​
File-backed workflows

Uploads often go through storage first, then the stored asset URL is passed into the downstream generation or analysis flow.

​
Important Route Groups

​
Auth

  • app/api/auth/route.ts
  • app/api/auth/google/route.ts
  • app/api/auth/signout/route.ts

​
Payments

  • app/api/payments/[provider]/route.ts
This is the shared webhook entrypoint for supported payment providers.

​
Chat

The chat area has the deepest API surface:
  • streaming chat
  • history
  • document generation
  • document upload/link/unlink/delete
  • document vectorization
  • file upload

​
Generative apps

Image, video, voice, vision, audio, and structured output each have their own generation routes with their own validation and provider requirements.

​
Good First Rule

If the route is tightly tied to one app’s UX, keep it in that app folder. If the route is shared across the whole product, it likely belongs under app/api.