Logo

Complete developer guide and best practices to help you get started quickly.

Tutorial

Using your API key

Walks through how to attach the API key in headers, inject it via environment variables, rotate it safely, and respond to leaks in production projects.

Your API key is the single credential that identifies you to Abestar. This tutorial skips the “how to obtain” part (see “Authentication”) and focuses on what to do once you have a key: where to store it, how to rotate it, and how to react when something goes wrong.

How to send the key

Every authenticated endpoint reads the X-API-Key HTTP header. The examples below assume the key is held in the ABESTAR_API_KEY environment variable.

Shell-side usage with an environment variable.

bash
# Set once per shell session
export ABESTAR_API_KEY="sk_live_..."

# Use it on every authenticated request
curl -X POST "https://abemono.abestar.com.tw/api/v1/translations/text" \
  -H "X-API-Key: $ABESTAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "text": "Hello", "target_language": "zh-TW" }'

Node usage reading the key from process.env.

javascript
// Server-side fetch — read from process.env, never bundle the key
const res = await fetch("https://abemono.abestar.com.tw/api/v1/translations/text", {
    method: "POST",
    headers: {
        "X-API-Key": process.env.ABESTAR_API_KEY,
        "Content-Type": "application/json",
    },
    body: JSON.stringify({
        text: "Hello",
        target_language: "zh-TW",
    }),
});

Never ship the key to the browser

If the key reaches a browser, anyone can read it. Always proxy requests through your server, or add the key on the server side of a BFF before forwarding. Frontend bundles, public-prefixed env vars (NEXT_PUBLIC_*, VITE_*), and public source repositories must never contain the key.

Key rotation

Hold at least two keys per account and rotate using the steps below for zero-downtime swaps. The console supports multiple active keys per account; until the old key is revoked, both keys remain valid concurrently.

  1. Create the new key in the console while keeping the old key active.
  2. Write the new key into your secrets manager or environment variables and redeploy affected services.
  3. Observe for 24–72 hours. Verify every instance is using the new key and that 401 unauthorized rates have not risen.
  4. Revoke the old key in the console. Any subsequent request using the old key returns 401 unauthorized.

Leak response SOP

If a key accidentally lands in version control or a frontend bundle, follow the steps below immediately. Record timestamps for each step to support post-incident review.

  1. Revoke the leaked key in the console immediately; revocation is irreversible and takes effect at once.
  2. Create a replacement key and update your secrets manager and deployment environments.
  3. Make sure no affected repository, git history, or CI log still contains the old key. If git history retains it, rewrite history or recreate the repo.
  4. Review recent usage records for anomalous request volume, unexpected endpoint calls, or unfamiliar geographies.
  5. Review the leak vector and add preventive controls (pre-commit secret scanning, env templates, CI secret checks).