Why Managers Should Care About "Where the Request Lives"

Many small teams' first version of AI integration puts the API call directly inside frontend components: as soon as the page loads, the browser hits the model provider directly. It works, but on day two after launch, you'll face a few unavoidable problems:

• The API Key is exposed on the client side—anyone can grab it by opening the browser's developer tools;
• Calls have no unified logging or usage tracking, so the monthly bill doesn't add up;
• Switching model providers means changing a dozen places in the code, and nobody dares touch it.

These aren't "programmer technical problems"—they're process and risk problems. The solution is simple: route all AI requests through a "gate" on your own server. In Next.js, that gate is the Route Handler. A gateway service (such as ThisToken.AI, an API platform aggregating multiple model providers), working with this gate, lets the team centrally manage keys, keep unified accounting, and switch models with ease.

This article walks you through three steps: register on the gateway and get a Key → write your first proxy endpoint → run a risk check before going live.

Step 1: Register on ThisToken.AI and Get an API Key

1. Go to the ThisToken.AI website and register a team account (don't just casually sign up with a personal email—you'll need to assign permissions to teammates later);
2. Go to the API Keys page in the console and create a Key. For the name, it's best to state its purpose directly, e.g., prod-nextjs-gateway;
3. The Key is shown in full only once at creation—immediately store it in a password manager or team vault;
4. Note the unified endpoint: https://api.thistoken.ai/v1—all model requests go through this single address, so switching models later doesn't require changing the domain.

As for costs, refer to the pricing page on the official site; we won't go into numbers here. Managers are advised to set a small top-up amount the first time—get it working first, then scale up.

Step 2: Write Your First Proxy Endpoint

Environment variable (.env.local, make sure to add it to .gitignore):

THISTOKEN_API_KEY=sk-xxxxxxxxxxxxxxxx

Create app/api/chat/route.ts:

// app/api/chat/route.ts
import { NextRequest, NextResponse } from "next/server";

const GATEWAY_BASE_URL = "https://api.thistoken.ai/v1"; // 统一网关入口

export async function POST(req: NextRequest) {
  try {
    const { messages } = await req.json();

    // 简单的输入校验：别让脏数据烧钱
    if (!Array.isArray(messages) || messages.length === 0) {
      return NextResponse.json({ error: "参数不合法" }, { status: 400 });
    }

    const upstream = await fetch(`${GATEWAY_BASE_URL}/chat/completions`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${process.env.THISTOKEN_API_KEY}`,
      },
      body: JSON.stringify({
        model: "gpt-4o-mini", // 换模型只改这一行
        messages,
        max_tokens: 1000,
      }),
    });

    if (!upstream.ok) {
      // 记录日志但不把上游错误细节原样抛给前端
      console.error("[gateway] 上游返回", upstream.status);
      return NextResponse.json({ error: "AI服务暂时不可用" }, { status: 502 });
    }

    const data = await upstream.json();
    return NextResponse.json({ reply: data.choices?.[0]?.message?.content ?? "" });
  } catch (e) {
    console.error("[gateway] 请求异常", e);
    return NextResponse.json({ error: "服务器内部错误" }, { status: 500 });
  }
}

The frontend call then becomes a regular internal request:

const res = await fetch("/api/chat", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ messages: [{ role: "user", content: "你好" }] }),
});

Run npm run dev, send a message from your page, and if you get a reply, it's working.

If the backend also uses a Python script for verification, the equivalent is:

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxxxx",
    base_url="https://api.thistoken.ai/v1",  # 网关统一入口
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "你好"}],
)
print(resp.choices[0].message.content)

Step 3: Three Pre-Launch Checks (For Managers)

1. Is the Key server-side only? Do a global code search and confirm the API Key only appears in process.env and can't be found in the frontend bundle. It's also recommended to create separate keys for development and production environments in the gateway console, so each can be revoked independently if leaked.

2. Is usage traceable? Add a line of logging in the Route Handler (user ID, model, token count), and reconcile against the call records in the gateway console weekly. In the early days after launch, the scariest thing isn't high costs—it's not knowing where they come from.

3. Does switching models only require changing one line? Because all requests go through the single entry point https://api.thistoken.ai/v1, switching models is just a matter of changing the model string. It's also recommended to put the model name into an environment variable, so switching requires no code changes or redeployment—much lower review cost.

Two Common Pitfalls

• No input validation: A user passes in a huge messages array and burns through your tokens. Always limit length and count.
• Passing upstream errors through as-is: Upstream error messages may contain sensitive details like your Key prefix. Wrap them into friendly messages, and keep the details only in server-side logs.

Summary

Converging AI requests into a Next.js Route Handler essentially establishes a rule for the team: keys never touch the client, every call leaves a trail, and switching models doesn't touch the architecture. The earlier you set this up, the more you save as the team grows. If you haven't registered a gateway account yet, start here: https://api.thistoken.ai/register

---

Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.