讓您自己的系統發出訪客證代碼

有些大樓只接受自家門禁所產生的憑證。在那些地點，Offision 產生的 QR 在閘門前毫無用處，因此必須讓 Offision 先等一等：訪客證建立起來但先扣住不寄，由您的訪客管理系統提供它要帶的代碼，之後才送到 訪客手上。

需要準備的東西

• 一套會自行產生訪客證代碼、並且能在訪問建立時被呼叫的訪客管理或門禁系統
• 閘門那篇文章裡建立的 API 憑證 — 同一組即可，不需要額外的權限範圍
• 一個您願意在測試期間暫停出證的地點。這個設定一開，該地點所有訪客證就不再寄出
• 一個下午。兩個呼叫必須在中間接上，而且各自都容易做錯

1. 開啟要求外部通行證編碼

打開該地點的訪問政策，開啟 要求外部通行證編碼。它位於 安全性 頁面的訪客證群組裡。

2. 提供代碼

兩個方向相反的呼叫，用工作流程來組合 — 因為回來的那個必須找到正確的訪客證。

• 出去。 一個以訪客證建立為觸發的工作流程，把訪問資料送到您的系統。您這端從中讀出訪客與期間， 產生一組代碼。
• 回來。 您的系統帶著那組代碼呼叫 Webhook。設為 記錄外部代碼 的 更新訪客證 動作會把它 記錄到訪客證上 — 這同時也解除了訪客證郵件的發送。

請把接收端觸發的 回應模式 設為 等待執行完成。在預設的 立即回應 (202 Accepted) 之下， Offision 一收到就回 202，您的系統無從得知代碼是否真的寫上去了 — 於是沒接到代碼的訪客證，看起來 和成功的完全一樣，最後發現問題的會是訪客本人。

3. 決定訪客看得到什麼

從這裡開始，訪客證的 QR 帶的是 您的 代碼，而不是 Offision 的 uid。這正是這個設定的用意：您的 讀卡機可以完全不呼叫 Offision，只靠自己的系統驗證。

開關旁邊還有兩個設定，兩者都關於訪客手上那份訪客證：

4. 確認是否成功

• 一筆新訪問。 在該地點建立一筆。訪客證應該出現在 Offision 裡，而且 還不會寄出郵件。
• 一來一回。 您的系統應該被呼叫到，它的代碼應該在數秒內出現在訪客證上，訪客證郵件接著會自動寄出。
• 訪客證本身。 打開訪客收到的東西。QR 應該帶著您的代碼，而印出來的代碼應該符合您在上面兩個設定 裡所做的選擇。
• 掃一次。 把同一組代碼送到簽到呼叫。它應該解析到同一位訪客。

最後一項就算是完全不打算在掃描後呼叫 Offision 的地點也值得做 — 訪客證上記錄的代碼跟您的系統以為 自己發出的代碼有出入，就是靠這一步發現的。

出問題的時候