簡訊驗證 API

1. GET /api/v2/tn101/get-services：服務目錄，包含下單時要用的識別碼以及目前價格。
2. POST /api/v2/tn101/request-number：訂購一個號碼。接受 service_key，以及選填的 state 和區碼。回應訂單 ID、號碼和到期時間。
3. GET /api/v2/tn101/get-number-details：用 order_id 輪詢。驗證碼送達前 pin 為 null，送達後就會包含驗證碼。這是 API 中成本最低的讀取操作，也是專為迴圈呼叫而設計的端點。
4. POST /api/v2/tn101/reject-number：釋出一個沒有收到任何東西的號碼。費用也是透過這個呼叫退回。

這條路徑不會主動推送任何東西給你，所以第 3 步是輪詢。如果你寧願被通知而不是主動詢問，帳號也會在訂單事件發生時發送 webhook，可在後台設定。

每個請求都要帶上 Authorization: Bearer <token>。Token 在後台的 API 存取設定中產生，並可隨時在那裡更換。更換會立即讓舊 token 失效，所以請先更新你的設定。

沒有有效 token 的請求會收到 401。帳號被停權或關閉了 API 存取，會收到 403。當 API 在全站停用時，每個端點都會回應 503，而不是假裝一切正常。

每個端點都以相同的三個欄位回應：

data 帶有資料內容，success 是用來判斷分支的布林值，summery 則是人類可讀的訊息。這個拼法不是本頁的筆誤：它是 API 一直以來使用的欄位名稱，存在於所有針對它撰寫的整合中，為了修正一個字母而改名會讓這些整合全部壞掉。請讀取 summery。

驗證失敗會回應 422，data 是一個欄位名稱對應錯誤訊息的物件，讓呼叫端能回報是哪個參數有誤，而不只是知道有東西錯了。

這套 API 是以真實電信路徑（而不是模擬環境）來測試註冊或密碼重設流程的實用方式：訂購號碼、用它操作你自己的表單、輪詢驗證碼，再驗證你的應用程式接下來的行為。它比 stub 慢，但能抓到 stub 抓不到的問題：號碼格式正規化、線路類型過濾，以及你的使用者實際會遇到的送達延遲。

API 沒有每秒請求數的限制，但下單有兩項配額，和後台套用的配額相同：

• 未結訂單。 一個帳號同時能保留的號碼數量有限。請輪詢並釋出，而不是同時大量開單。
• 每日取消與到期的訂單數。 超過每日額度，下單功能會暫停一段時間，重複超過時暫停時間會延長。無論驗證碼是否送達，每次保留都會消耗真實的號碼資源，而這正是配額要保護的。

兩者在臨時號碼中有更詳細的說明，那裡解釋了一筆訂單如何進行。