用 Offision 訪客證開啟您的閘門
您的旋轉閘門掃描 Offision 訪客證，向 Offision 詢問它此刻是否有效，並記錄到訪。 三個 API 呼叫、一組憑證，回傳的是可以直接依循的判定，而不是要自己解讀的狀態。
這是大樓既有的門禁 — 旋轉閘門、閘機、大堂讀卡機，或另一套訪客管理系統 — 與 Offision 訪客管理搭配運作的方式。訪客證由 Offision 發出；您的讀卡機掃描它，向 Offision 詢問它此刻是否有效；開啟閘門的是您的系統；而同一個呼叫也記錄了這個人已經進來。
訪客證在任何人到達之前數天，就已經用郵件送到訪客手上。閘門前只需要一個呼叫，同時完成詢問與記錄，您的閘機依回傳的判定開門。
1. 建立 API 憑證
開啟API認證設定憑證本身 — 怎麼命名、IP限制、用戶端 ID 與密鑰在哪裡、以及怎麼換成權杖 — 由連接您自己的系統 說明。這一個請以使用它的系統來命名：日後您會在稽核記錄裡讀到這個名稱，大堂旋轉閘門 比 API key 3 容易辨認得多。
閘門只需要一列 API 權限範圍：
| 權限範圍 | 用途 |
|---|---|
visitor.readwrite | 查詢掃描到的代碼，以及記錄到訪與離開 |
新建立的憑證，包含 API 權限範圍與 IP限制。
用戶端 ID 與 用戶端密鑰 不在這張表單裡 — 它們由 Offision 產生，憑證儲存後顯示在詳細面板中。
用戶端 ID 與密鑰，以及重新產生密鑰的操作。
2. 檢查掃描到的代碼
把讀卡機讀到的內容原樣送到驗證呼叫，連同閘門所在的大樓一起。您不需要自己判斷手上是哪一種代碼 — QR 裡的訪客證 uid、印在訪客證上的六字元訪客代碼、您自己的系統發出的代碼，或八位數的長期訪客證代碼，都會以同樣的方式解析。
回傳的是一個判定，而不是要您自己解讀的狀態 —— valid、expired、cancelled、
wrongLocation 等等 —— 同時回傳的還有 isGranted，那才是閘門真正依循的欄位。所有判定都列在訪客證 API 會回傳什麼。
3. 記錄到訪
上面的檢查不會改變任何東西。略過這一步，每張訪客證都會永遠停在 未訪問：接待處看不到訪客抵達、接待人不會收到通知，訪問報表也一直是空的。
簽到呼叫接受同樣的代碼、以同樣的格式回答，並在判定為 valid 時記錄到訪。所以一個既要放行又要記錄的閘門，只需要 一個 呼叫，而不是兩個 — 步驟 2 那個單獨的檢查，是給只做驗證的讀卡機用的，例如出口側的掃描器或大堂的顯示裝置。
簽退呼叫是它的鏡像，給同時讀取離場的閘門使用。
兩者每次掃描都可以安全呼叫，也都會在判定之外回傳 action，說明實際記錄了什麼 —— 訪客還在裡面時的第二次掃描，是刻意什麼都不寫的。判定、action，以及簽退和重新進入的差別，見訪客證 API 會回傳什麼。
4. 確認是否成功
以下四項會各自獨立失效，請全部測試：
- 一張正常的訪客證。 在期間內掃描真的訪客證。您應該取得
valid、isGranted為 true 與訪客姓名，閘門也應該打開。 - 回寫。 之後在 Offision 裡看那張訪客證。它應該已經變成 訪問中，受訪者也應該收到通知。
- 同一張再掃一次。 第二次仍然應該放行、回傳
alreadyCheckedIn，而且簽到時間完全沒有變動。 - 一張不該過的訪客證。 刻意掃描一張已取消的訪客證，以及一張明天的訪客證。兩張都必須被拒絕。
最後一項是最常被略過的。一台只用有效訪客證試過的讀卡機，就是一台誰都放行的讀卡機。
出問題的時候
從放行所有訪客證的閘機，到誰的到訪都沒記錄的閘機，實際會遇到的九個症狀和它們的成因，都在閘機放行了應該拒絕的訪客證。