取得您的 API 金鑰
在 Console 中建立組織與應用程式，並取得呼叫 SDK 所需的 client_id 與 client_secret。
每次 SDK 呼叫都需要憑證。本指南將帶您在約兩分鐘內取得 client_id 與 client_secret，供下一篇指南
— 您的第一次 SDK 呼叫 — 使用。
client_id 與 client_secret 的用途
您在下面取得的 client_id/client_secret 組合，是用於 POST /auth/token 的 Basic-auth
憑證 — 這是發行短效、每位使用者一個的 session JWT（供瀏覽器 SDK 使用）的建議方式（見
選擇您的認證模式）。您的 backend 會以
Authorization: Basic base64(client_id:client_secret) 送出，平台則會回傳一個限定於您 app
allowed_pipelines 範圍的 JWT。
它們不是伺服器端 API 金鑰模式所用的 x-api-key 那種憑證，也不是 JWT 簽章密鑰。如果您改用
整合到您自己的伺服器 中說明的（舊式、替代方案）
自行簽發 JWT 做法，那條路徑需要另一組密鑰 — 一把 per-app 的簽章密鑰 — 這把密鑰完全不是從
Console 這個流程發出的。它是由平台維運方另外透過安全管道提供的，只有在您刻意選擇自行簽發、而非
呼叫 POST /auth/token 時才需要用到它。
那靜態的 x-api-key 呢？
本指南涵蓋 session-JWT 模式所用的 client_id/client_secret 組合 — 這是大多數整合情境建議採用
的路徑。靜態的 x-api-key 則是同一個 app 的另一種、可自助取得的憑證：在 Console 中開啟該 app
的詳細頁面，點擊「API Key」卡片下方的 Regenerate API Key 即可。這把金鑰只會顯示一次；請將它
存放在您伺服器的 secrets 儲存庫中。
與 client_id/client_secret（透過 POST /auth/token 換取短效 JWT）不同，x-api-key
是直接放在每次呼叫的 header 中使用 — 不需要額外的發行步驟。它與同一個 app 綁定：只能呼叫該 app
allowed_pipelines 清單中的 pipeline，並且會從該 app 的 org wallet 扣款，這點與 session JWT
相同。它的取捨在於每位使用者的歸屬 — 每次呼叫看起來都像是「這個 app」發出的，而不是某個特定使用者。
對於在意每位使用者歸屬的情境，請改用 session JWT 模式。完整比較請見
選擇您的認證模式。
1. 登入 Console
開啟 Console 並登入，或建立一個帳號（50 個免費額度，無需信用卡）。
2. 建立組織
建立一個組織。您將成為該組織的擁有者。組織負責管理您的應用程式、使用量及帳單。
3. 建立應用程式
在 Applications → New application 中輸入名稱。這個應用程式就是您的伺服器呼叫 SDK 時所使用的 身分。
4. 複製 client_id 與 client_secret
系統會顯示一組 client_id 與一次性的 client_secret。secret 只會顯示一次 —
請立即複製到您伺服器的 secrets 儲存庫中。它絕對不能出現在瀏覽器程式碼或公開的 repo 中。
5. 啟用 pipeline
前往 Tools，選擇一個 pipeline（建議先從 translate-string 開始），然後點擊
Enable onto application。這會將它加入應用程式的 allowed_pipelines 允許清單 — SDK（以及任何透過
POST /auth/token 發行的 JWT）都只能呼叫應用程式已啟用的 pipeline。
下一步：您的第一次 SDK 呼叫 會使用這組
client_id/client_secret 進行一次真正的翻譯呼叫。