驗證與 API 基底網址

Token 從哪裡來

這份快速入門使用的 scoped private API 以 TeamSync 登入 JWT 驗證。前端應沿用應用程式既有登入流程回傳並保存於執行階段的 access_token，不要為文件網站另做一套登入，也不要把 token 寫死在原始碼、測試資料、curl 檔案或版本控制中的環境檔。

Token 代表目前登入使用者；能不能操作某張表，還會由範圍與 ACL繼續判斷。換句話說，有合法 JWT 不等於擁有每一個端點的權限。

Authorization header

這份入門中的 scoped private API 請求都把 JWT 放在標準 Bearer header：

Authorization: Bearer <JWT_FROM_APP_LOGIN>

在前端 request wrapper 中，header 會像這樣組成：

const response = await fetch(url, {
  headers: {
    Authorization: `Bearer ${accessToken}`,
  },
})

curl 範例則從目前 shell 的 TOKEN 變數讀取，不把值留在文件或腳本裡：

curl "$BASE_URL/private/module/custom_tables/company/tables" \
  --header "Authorization: Bearer $TOKEN"

API 基底網址

組合請求時，直接把 catalog 顯示的完整路徑接在基底網址後面。例如 staging 的公司層級資料表清單是 https://api.scfg.io/private/module/custom_tables/company/tables。

本站工具如何保存 token

注意：本站所有互動工具只會把 Base URL 與 token 存在目前瀏覽器來源的 localStorage（key：custom-tables-docs:engine-config）。請求由瀏覽器直接送到你選的 API 基底網址；文件網站沒有代送請求或保存 token 的伺服器。

localStorage 在關閉分頁後仍會保留。共用電腦使用完畢後，請在工具中清空 token，或在瀏覽器主控台執行：

localStorage.removeItem('custom-tables-docs:engine-config')

準備好 JWT 後，可以先到 API Playground確認驗證，再進行第一張資料表的五次呼叫。