Two Years of Building AI Features: Keep the Key on the Server from Day One

In my two years leading a team building AI features, what I fear most isn't poor model performance—it's the moment I open the backend logs and find that an API Key deployed in a mini-program for three months suddenly spiked to forty times its normal call volume in the early morning hours. After that incident, I spent a long time doing a post-mortem, and my conclusion was: when a mini-program connects directly to AI services, the key should never leave the server from day one. This article lays out our complete remediation plan, giving readers who also lead small teams a solution they can copy directly.

1. First, Think It Through: Where Does the Risk Come From

Many independent developers' first architecture looks like this: the mini-program frontend makes requests directly to the model service's API, with the Key hardcoded in the frontend code. This approach is fine during the demo stage, but once you go live, there are three unavoidable risks:

1. The Key is cash. Anyone who obtains the mini-program package can decompile it and see your Key. It's equivalent to a credit card with no spending limit.
2. No budget gate. Direct frontend connections mean usage depends entirely on user behavior. You have no interception mechanism on the server side, and you only discover abuse after the fact.
3. No auditability. Who called how many tokens in what context, and how much money was spent—these questions can't be answered in a frontend-direct architecture, yet these are exactly the numbers managers need most.

The solution is simple: add your own proxy layer between the mini-program and the AI service, so the Key only exists on the server side. Our team chose to use a unified AI gateway (ThisToken.AI) as the model outlet, with our own proxy layer handling only authentication, rate limiting, and accounting.

2. Three Process Checkpoints Managers Should Watch

Before implementing the solution, I recommend establishing these three things as team rules first—this matters more than technology choices:

Checkpoint one: Key lifecycle management. Registering the gateway account, generating Keys, who has permission to view them, how often they rotate—someone needs to own these. Our team's rule: Keys only appear in server-side environment variables; any Key found in the code repository is treated as an incident.

Checkpoint two: Hard limits on quota and budget. Set quota limits for each Key in the gateway console, and apply per-user rate limiting in your own proxy layer. The point of double insurance: even if one layer fails, the loss is calculable.

Checkpoint three: Ownership of call logs. Every call recorded by the proxy layer should be traceable to a functional module, so when you pull the bill at month's end, you can directly answer "how much did the chat module cost, how much did the recommendation module cost." This determines how next month's budget gets allocated.

3. Get Running in Ten Minutes: Register, Get a Key, First Code

Now for the hands-on part.

Step one: Register an account. Go to https://api.thistoken.ai/register and register with an email. I recommend using a shared team work email rather than a personal one—the account itself is an asset, and ownership should be clear.

Step two: Create an API Key. After logging in, go to the console's API Key management page, create a new Key, and copy and save it immediately. Note that the platform only shows the full Key once at creation. For specific billing methods and quotas, refer to the official pricing page—don't rely on secondhand information.

Step three: Run the first piece of code. Here's Python. The core of the code is base_url="https://api.thistoken.ai/v1"—all requests point to this unified entry:

import os
from openai import OpenAI

# Key 只从环境变量读取,绝不写进代码
client = OpenAI(
    api_key=os.environ["THISTOKEN_API_KEY"],
    base_url="https://api.thistoken.ai/v1"
)

def chat(prompt: str) -> str:
    """代理层的核心函数:小程序后端只暴露这个能力"""
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "你是一个简洁友好的助手。"},
            {"role": "user", "content": prompt},
        ],
        max_tokens=300,
    )
    return resp.choices[0].message.content

if __name__ == "__main__":
    print(chat("用一句话介绍什么是API网关"))

Running this code successfully proves three things at once: the account is valid, the Key is correct, and the network path works. I recommend having every new team member run it during onboarding as a standard environment verification step.

4. Round Out the Proxy Layer into a "Manager-Ready" Architecture

The code above is just link verification. In production, the proxy layer needs at least four additions—none are complicated, but missing one means losing a layer of risk control:

• User authentication: Verify the mini-program's login state (e.g., WeChat session); reject requests without valid credentials outright;
• Per-user rate limiting: N calls per user per day, with a friendly message when the limit is exceeded, to prevent a single user from draining the budget;
• Module tagging: Tag call logs with functional labels so costs can be broken down by module in the monthly bill;
• Failure fallback: When the model times out or errors, give users a degraded response instead of leaving the mini-program on a blank screen.

This setup can be deployed on any lightweight cloud server. Expose only the interfaces you define; the mini-program frontend calls your domain and never touches any Key.

5. Final Thoughts from a Management Perspective

The technical solution itself can be written in half a day, but what truly keeps a team running safely is process: who holds the Keys, who monitors the quotas, who reviews the bills. Write these three questions into your team documentation—only then does the proxy code matter.

That anomalous early-morning call spike ultimately caused limited damage because we had set a quota cap in the gateway console beforehand—the loss stopped at an acceptable number. The only architectural change we made afterward was moving the Key from the mini-program side into the server-side proxy—one remediation, in exchange for sleeping soundly every night since.

If you haven't registered a unified AI gateway account yet, start here: https://api.thistoken.ai/register . Register first, get your Key, run the code above—and we'll talk about the remaining risk controls next time.

---

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