帳號授權

匯入會話

透過匯入既有的 session URL 或 cookie/會話內容完成認證。客戶端範例請使用佔位符，切勿在 log 中暴露真實會話內容。

POSThttps://api.unifyport.ai/v1/accounts/{account_id}/auth/session

呼叫前準備

在伺服器端使用資源所屬工作區的 X-Api-Key，執行範例前替換所有預留位置。

WhatsApp Protocol 是獨立管道，使用 provider=whatsapp-protocol。目前僅支援工作階段匯入（auth_mode=session），透過既有工作階段憑證完成授權。 WhatsApp Protocol 接入授權

參數從哪裡取得

account_id: 從建立或查詢帳號的回應取得 data.id。帳號屬於 X-Api-Key 對應的工作區。取得帳號

請求

curl -X POST "https://api.unifyport.ai/v1/accounts/{account_id}/auth/session" \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "session_url": "https://example.com/account.session"
}'

請求參數

請求標頭

X-Api-Key

string必填

工作區 API Key，工作區會由此標頭解析得到。

Content-Type

string必填

傳送 JSON 請求內容時請使用 application/json。

路徑參數

account_id

string必填

用於該 authentication 路由的識別字。

請求內容

session_url

string

既有渠道會話的 URL 或參考。

format: uri

whatsapp-protocol

object

WhatsApp Protocol 會話匯入憑證，只能透過此巢狀物件提交至 /v1/accounts/{account_id}/auth/session，不能透過 provider_data 提交。提供此物件時，phone、static_pub_key、static_pri_key、identity_pub_key 和 identity_pri_key 必填。回應不會回傳協定金鑰或其他敏感憑證。phone 用於身分一致性驗證；協定公鑰、私鑰僅供上游啟動使用。edge_routing 由平台固定注入，不得提交。

phone

string

電話號碼可包含空格、連字號、括號或加號；伺服器會正規化為正數字串。

minLength: 1

platform

integer

WhatsApp Protocol 會話匯入的平台值（int32）。

format: int32

app_version

string

WhatsApp Protocol 會話匯入的應用程式版本。

server_address

string

WhatsApp Protocol 會話匯入的渠道伺服器位址。

fallback_server_addresses[]

string[]

WhatsApp Protocol 會話匯入的備用伺服器位址清單。

country

string

WhatsApp Protocol 會話匯入的國家代碼。

device

integer

WhatsApp Protocol 會話匯入的裝置值（uint32）。

format: uint32

static_pub_key

string

協定公鑰；僅供寫入。

minLength: 1

static_pri_key

string

協定私鑰；僅供寫入。

minLength: 1

identity_pub_key

string

身分公鑰；僅供寫入。

minLength: 1

identity_pri_key

string

身分私鑰；僅供寫入。

minLength: 1

hash

string

已棄用的相容欄位；目前值會被忽略且不儲存，建議省略。

peer_kem_public

string

對端 KEM 公鑰；僅供寫入。

auth_hex_data

string

目前的十六進位認證資料；僅供寫入。

authhexdata

string

已棄用的舊版十六進位認證資料欄位；僅供寫入。

pq_handshake_mode

string

WhatsApp Protocol 會話匯入的 PQ 交握模式。

use_xxkem_handshake

boolean

WhatsApp Protocol 會話匯入是否使用 XXKEM 交握。

如何理解結果

先讀取授權結果，再檢查 runtime_status。匯入與建立連線是不同階段。

回應 200 OK

{
  "request_id": "<REQUEST_ID>",
  "data": {
    "account_id": "acc_example",
    "status": "authorized"
  }
}

回應內容

account_id

string

本回應所對應的渠道帳號。

status

string

目前授權流程狀態，例如 pending_auth、awaiting_qr_scan、awaiting_code、pending、passkey_required、passkey_pending、passkey_confirmation、passkey_confirmation_sent、authorized 或 failed。

回應

200

200 OK

請求成功，回應內容範例如上。

400

請求錯誤

請求內容、路徑或參數無效。

401

未授權

X-Api-Key 請求標頭缺少或無效。

409

衝突

目前操作與既有的渠道帳號或資源衝突。

500

伺服器錯誤

服務遇到了未預期的錯誤。

502

上游閘道錯誤

渠道轉接器或上游渠道未能完成此操作。

失敗後如何處理

檢查 HTTP 狀態和 error.code/numeric_code，保留 request_id。依原因修正參數、繼續授權或檢查狀態。重試傳送及寫入前確認上次結果，避免重複操作。錯誤碼參考

invalid_request · 10000 · 400: 檢查必填欄位、格式與渠道條件，修正請求後再呼叫。
invalid_api_key · 11001 · 401: 檢查 X-Api-Key 與工作區是否有效。
provider_invalid_request · 30001 · 400: 檢查必填欄位、格式與渠道條件，修正請求後再呼叫。