概觀
registerBusiness mutation 會在 Fluz 平台上建立一個企業帳戶。在單次呼叫中它會：- 建立與申請人綁定的企業帳戶——也就是你提交權杖所屬的 Fluz 使用者，
- 儲存法人實體資料——法定名稱、組織型態、稅務編號、註冊州別、法定地址、類別，以及帳戶預期用途，
- 儲存你提供的每位所有者之實益所有權資訊，
- 開啟一個KYB 審查個案，並
- 將新的企業帳戶連結到你應用程式的 OAuth 授權。
accountId，kybStatus 為 SUBMITTED。
本頁是該 mutation 的參數與錯誤參考。關於前置需求、周邊的呼叫順序，以及如何追蹤個案至決議，請先閱讀註冊與驗證企業。
必要範圍（scopes）
使用企業帳戶的權杖會在 mutation 執行前即被 schema 拒絕。不接受基本驗證（Basic authentication）。
基本 mutation 結構
參數
地址格式化使用下方的結構化欄位格式化
businessLegalAddress 與每位所有者的 address，需為真實且可投遞的地址，且城市 / 州 / 郵遞區號需一致。兩者皆可為國際地址（國家名稱，ISO 3166；部分國家受限，如俄羅斯或伊朗）。企業法定地址會額外透過地址驗證供應商驗證，若無法確認則以 BS-0002 拒絕；所有者地址僅進行欄位與州/省檢查。請參閱地址格式規範。BusinessLegalAddress
儲存的地址將是供應商正規化後的版本，
city、state 與 postalCode 會轉為大寫——不一定與你提交的字串完全相同。
RegisterBusinessConfirm
兩個欄位皆為不可為 null，請同時傳送。僅會強制符合你名單的那一個——將其設為
true，另一個設為 false。
BusinessOwner
OwnerAddress
BusinessStructure（列舉）
不在此清單內的結構會以
BS-0005 拒絕。信託、非營利與其他實體型態將視情況處理——在整合前請先聯絡你的客戶經理。
BusinessAccountUsage（列舉）
請傳送所有符合的值。若皆不符合，請省略
businessAccountUsage 並於 businessAccountUsageOther 描述預期用途。傳送列舉外的值會回傳 BS-0004。
實益所有權要求
KYB 審查仰賴你一次就提供正確的所有權資訊。請蒐集並提交：- 每一位直接或間接持有25% 或以上股權的自然人。
- 控制人——對實體管理負有重大責任的自然人（CEO、CFO、管理成員、普通合夥人或類似職務）——即使沒有股權。以
isControlPerson: true傳送。名單中必須有且僅有一位帶有此旗標。 - 申請人——你的 Bearer 權杖所屬的使用者——需以
emailAddress或phoneNumber匹配。必須有且僅有一位所有者匹配，且該所有者不可為isInvited: true。
- 陣列的
ownershipPercentage總和不可超過 100，但並不需要等於 100。若一間公司由三位自然人分別持有 40/35/25，再加上一位無股權的 CEO，請提交四位，持股分別為 40、35、25 及 0。 - 若持股的是實體（而非自然人），請穿透到其背後的自然人並提交該等個人。
- 所有者的 email 與電話在名單中必須唯一。
title為自由文字，但會由人工審閱。請使用可辨識的職稱（如「Chief Executive Officer」、「Managing Member」），而非內部縮寫。
需要完整身分資料的是誰
每位所有者所需提供的資訊取決於其角色。每位所有者都需要基本欄位；只有部分需要額外的身分資料。
基本欄位：
firstName、lastName、title、ownershipPercentage、isControlPerson、isInvited、isUsPerson，以及 emailAddress / phoneNumber 至少其一。
完整身分資料： dob 與 address，且當 isUsPerson 為 true 時需加上 lastFourSsnDigits。當 isUsPerson 為 false 時，請省略 lastFourSsnDigits——該所有者會在註冊後透過 requestOwnerDocumentVerificationLink 進行文件驗證。
驗證速查
多數錯誤都是格式問題。提交前請檢查：文件
當申請人不是實益所有人或控制人時，需要提供授權簽署人文件，且任何結構在 KYB 審查期間皆可能被要求提供更多文件。兩種路徑都在同一頁涵蓋：提交企業文件
上傳端點、可接受的文件，以及當合規要求更多資訊時該如何處理。
回應細節
RegisterBusinessError
驗證與商業規則失敗會回傳在回應 payload 內部，而非頂層 GraphQL 錯誤。請以是否存在
error（或 success === false）作為判斷依據，而非依賴 HTTP 狀態碼。權限失敗是例外：錯誤的 scope、錯誤的帳戶型態，或使用 Basic auth 會在 resolver 執行前被拒絕，並以頂層 errors 陣列呈現，同時 data.registerBusiness 會是 null。cURL 範例
回應範例
成功
錯誤
錯誤代碼
在 payload 內回傳，並帶有success: false：
在頂層
errors 陣列回傳，且 data.registerBusiness 為 null：
所有者名單問題會以
ARG-0001 回報，而非 BS-0003。BS-0003（InvalidOwnerInformation）存在於共用錯誤型錄中，但此 API 不會回傳該代碼。在測試環境進行測試
- 針對上面範例中的測試環境 GraphQL 端點註冊。請參閱測試環境與正式環境。
- 地址請使用測試地址，以確保可確定性地通過驗證——法定地址會透過實際的地址驗證供應商驗證，虛構街道會失敗。
- 測試環境的 EIN 仍須符合
XX-XXXXXXX格式，但不需對應真實實體。 - 所有者電話號碼必須為該國家可能存在的號碼。
+15551234567會失敗，因為555不是已指派的美國區碼；請使用真實區碼並搭配555交換機，例如+14155551234。 - 因使用者無法同時持有兩個開放中的申請（
BS-0007），請以不同的測試使用者測試重複的註冊流程。
最佳實務
- 先在用戶端進行驗證。幾乎所有錯誤代碼都屬於你可在送出前攔截的格式或選擇問題。這將大幅提升導入完成率。
- 預期一次只會回傳一個錯誤。驗證會在發現第一個問題時即停止，且法定地址會被優先檢查，因此被拒絕的提交可能存在多個問題。
- 在執行時擷取類別。切勿將類別 UUID 硬編碼。
- 對每位所有者都傳送
isUsPerson。這是名單被拒的最常見原因。 - 不要在 KYB 被駁回時自動重試。重新提交不會改變結果，且會造成重複個案。
- 立刻儲存
accountId。它是你對此申請案唯一的識別，也是支援單位會要求的參考資料。 - 如實傳達審核中狀態。告訴使用者其企業正在審核中以及大致所需時間，而不是直接帶入尚無法交易的企業控制台。
- 第一次就完整蒐集所有權資訊。缺漏實益所有者是審查停滯且要求補件的最常見原因。
備註
businessAccountUsage與businessAccountUsageOther必須至少提供其一。- 使用者在已有進行中的申請時無法註冊新企業。
- 無冪等鍵。重複提交會被開放申請檢查所阻擋。
- 驗證會在任何資料寫入前進行，且實體、申請、章程、與地址紀錄會於單一交易中建立——被拒的提交不會留下任何資料。
- 你提交的
taxId會在儲存前被權杖化，且不會在任何讀取操作中回傳。
相關頁面
KYB 概觀
前置需求、端到端流程，以及如何追蹤個案至決議。
企業類別
取得此 mutation 所需的類別與子類別 ID。
提交企業文件
上傳授權文件並回應 KYB 文件要求。
企業 KYB 狀態
提交後讀取 KYB 狀態與各所有者的驗證進度。
所有者驗證連結
為走文件路徑的所有者產生身分驗證連結。
地址格式規範
規範企業法定地址與所有者地址物件的規則。