userId 與 accountId。
當使用者授權你的應用程式時，你會將自家的識別碼附加到該授權上。Fluz 會儲存你的識別碼與該使用者 Fluz 帳戶的配對關係，且範圍限定在你的應用程式。從此之後，你就可以在產生權杖、發送轉帳、以及對應 webhook 事件時，以你自己的 ID 來引用該使用者。
實際效益：你永遠不需要建立 Fluz-ID 對照表。 一個 webhook 抵達時，內含你的使用者 ID，你就能路由它。無需 join、無需快取、也不需要對賬作業。
一個值，三個欄位名稱
相同的值會在不同介面以不同名稱出現。這是本頁最常見的混淆來源，開始前值得先記住。
因為它被嵌在 access token 中，所以關聯能在 token 重新整理後依然存在——你在授權時指派一次，之後都會持續有效。
選擇識別碼
代價最高的錯誤是把它綁錯對象。 external reference ID 用來永久識別一個_人_——不是一筆交易、不是一次撥款批次、不是一個工作階段，也不是一張訂單。若你傳的是每筆交易都有新值的識別碼，第一次轉帳會成功，但第二次會為同一個人建立第二個對應，導致同一位使用者被分叉成多個，且無法合併。若你發現自己每次操作都在產生新值，你要的是 idempotency key，而不是 external reference ID。
規則
指派方式
標準 OAuth 應用程式
在引導使用者前往同意頁的授權 URL 上附加external_id（參見 Client-facing OAuth grant flow）：
usr_8f3d2a91 記錄到該使用者對你應用程式的授權上。
此步驟是可選，但強烈建議。若你之後才導入，將需要逐一讓使用者重新授權以回填。
Widget 應用程式
對於 widgets，此值會作為簽署之預先核准交易權杖中的externalId claim 傳遞，與金額與交易類型並列。你必須在伺服器端產生；這不是前端初始化選項。請參見 Set Up Your Server。
externalId 與 jti 在同一個權杖中但回答不同的問題。externalId 是_哪位使用者_——在使用者生命週期中保持穩定。jti 是_哪一筆交易_——每次都不同。重用 jti 會破壞冪等性；更改 externalId 則會把你的使用者分叉。使用方式
指定轉帳目的地
在建立轉到另一個 Fluz 帳戶的錢包轉帳時（參見 Transfer to Another Fluz Wallet），可用你自己的 ID 來標示目的地，而不是 Fluz 帳戶 ID：destination.accountId 或 destination.externalReferenceId 二擇一——切勿同時提供。目的地使用者必須已授權你的應用程式，否則轉帳會被拒絕。
對應 webhook 事件到你的使用者
Webhook 載荷會攜帶externalReferenceId，因此你能在沒有對照表的情況下路由事件：
取得以使用者為範圍的權杖
generateUserAccessToken 並不接受 externalReferenceId——它以 userId 與 accountId 來識別使用者（參見 Generate a User Access Token）。
對於你以自家 ID 來引用的使用者，請改用 OAuth 流程。該授權已帶有你的識別碼，而你在 /token/exchange 用授權碼交換得到的權杖，會以該使用者為對象簽發且內嵌此關聯。請見 Exchange an OAuth Authorization Code。
端對端
一位使用者，一個識別碼，四個介面。1
你的系統已經認得這個人
你資料庫中的使用者
usr_8f3d2a91 點擊 Connect Fluz。2
在同意時指派
你以
external_id=usr_8f3d2a91 重導向至 /authorize。他們登入、必要時完成驗證，並核准你的 scopes。Fluz 將 usr_8f3d2a91 綁定到他們的帳戶，且僅限於你的應用程式。3
交換
你的回呼把
code 交換成 accessToken 與 refreshToken。此關聯已被內嵌，故能在之後每次重新整理時持續存在。你將權杖儲存到 usr_8f3d2a91 名下——你的資料結構中不需要 Fluz 的 UUID。4
操作
你以
destination: { externalReferenceId: "usr_8f3d2a91" } 向他們支付，使用你自家的 ID 作為地址。5
對賬
完成通知的 webhook 會攜帶
externalReferenceId: "usr_8f3d2a91"。你直接將其路由到該使用者紀錄並標記撥款已結清。無需 join、無需對照、無需快取。生命週期
回填既有授權
若某位使用者在你導入 external reference ID 之前就已授權你的應用程式，你可在之後的再次授權時提供一個，Fluz 會將其回填到既有授權——前提是該授權尚未有此值。既有值永不覆寫。以不同值重新授權
因為既有值永不覆寫，對於已經有值的使用者再次傳入_不同的_external_id 並不會改變對應。請將第一次設定視為永久。若你的使用者 ID 不穩定，請為 Fluz 產生一個專用且不可變的 ID，而不是重用可能會遷移的值。
你方刪除使用者
永遠不要重複使用識別碼。若你將使用者永久刪除，後續又把同一個主鍵重發給不同的人，新的那個人會繼承舊的對應——以及舊使用者的 Fluz 帳戶。請使用 UUID，或是永不重設的單調遞增序列。驗證規則與錯誤
疑難排解
external reference ID 不是什麼
- 不是 Fluz 的
userId或accountId。那些是 Fluz 簽發的 UUID；這個則是由你簽發。 - 不是 idempotency key。那是 API 呼叫中的
idempotencyKey與 widget 權杖中的jti，且是每次操作唯一。external reference ID 則是每個人唯一。 - 不是 OAuth 流程中的
state參數。state是每次授權嘗試的 CSRF 防護，且不會被儲存。 - 不是 出現在提領紀錄或已連結資金來源上的外部帳戶識別碼。那些是銀行與處理器紀錄的識別碼，而非使用者。
後續步驟
授權流程
在這裡為 OAuth 應用程式指派識別碼。
設定你的伺服器
在這裡為 widget 應用程式指派識別碼。
轉帳到另一個 Fluz 錢包
以你自家 ID 指定轉帳目的地。
設定應用程式 webhooks
接收會回傳該識別碼的事件。