郵箱驗證 API
透過 HTTP 進行完整 SMTP 郵箱檢查的即時郵箱驗證 API——面向送達率的準確驗證，而非僅格式校驗。
全部驗證 API 模式，同一端點
每種驗證類型都可透過同一 REST 郵箱驗證 API 存取。
單封郵箱驗證
POST /verify — 一次即時郵箱驗證 API 呼叫，響應時間小於 3 秒。在一個 JSON 物件中回傳狀態、送達率、品質評分與風險標誌。
批量驗證
POST /verify/bulk — 每次 API 呼叫最多可同步驗證 50 個地址。所有結果會在同一個 API 響應中回傳，採用與即時郵箱驗證 API 單一地址呼叫相同的 schema。
非同步文件處理
POST /verify/file — 向 API 提交 CSV 或 Excel 檔案進行後台處理。API 任務完成後透過 webhook 回呼交付結果。
官方 SDK
面向驗證 API 的型別安全客戶端函式庫，支援 Python、Node.js、Go 與 PHP。失敗自動重試、完整錯誤處理，以及跨語言一致的響應型別。
每次郵箱驗證 API 呼叫包含什麼
每次即時郵箱驗證 API 呼叫都會自動執行相同的多層檢查。
驗證 API 中的 Webhook 支援
非同步接收 API 結果並查詢訊息歷史。
非同步投遞
創建 Webhook
註冊 HTTP 端點，在任務或批次完成時立即接收 API 結果。該 API 支援自訂 payload、失敗自動重試，以及按任務或全域設定。
- 含結果摘要的任務完成事件
- 投遞失敗自動重試
- 按任務或帳戶級配置
消息歷史
查詢消息
存取完整 webhook 事件日誌，以檢索歷史 API 結果、除錯投遞失敗或重放錯過的通知。API 事件保留 30 天。
- 按任務 ID 或日期範圍查詢事件
- 重放錯過或失敗的投遞
- 30 天事件保留
AI 原生的驗證 API 整合
無需從零編寫驗證邏輯，即可把該 API 接到所有主流 AI 客戶端與 SDK。
端點內部
郵箱驗證 API 每次呼叫證明什麼
郵箱驗證 API 的價值取決於響應欄位背後的證據。這一份回傳的是郵箱級事實，而不是把語法判斷包裝成結論。
語法與路由只是成本低的檢查層，並不是答案
每次呼叫郵箱驗證 API 都會規範化地址、檢查結構，並解析該域名的 MX 記錄。這兩層 API 快速，也不會對收件方發起請求，因此會先執行，在 SMTP 階段前排除明顯無效的地址。
只做語法的 API 停在這裡，並把結果稱為有效。這就是校驗端點與繼續查到郵箱本身的免費郵箱驗證 API 之間的差距。
SMTP 才是驗證 API 名副其實之處
該 API 與接收伺服器開啟真實的 SMTP 會話，並探測收件路徑。不會傳送郵件正文，不會點擊確認連結，也不會有任何內容落入對方收件箱。我們的免費郵箱驗證 API 會把伺服器響應讀到足以區分「接受該收件人」與「永久拒絕」。
這才使它成為即時郵箱驗證 API，而不是附上行銷文案的 DNS 查詢。證據來自真正會接受或拒絕你郵件的那套系統。
風險標誌與狀態同行，在同一響應裡
API 回傳的一個 JSON 物件攜帶送達狀態、品質評分、風險等級、原因碼，以及一次性、角色帳號、Catch-All 與免費網頁郵箱標誌。你的應用不需要第二次 API 呼叫就能知道結果為何如此。
把標誌放在狀態旁邊是刻意的。一個會收信的角色地址和一個會收信的個人郵箱都是 deliverable，只有你的產品知道哪一個屬於當前工作流。
不確定的答案保持不確定
灰名單、服務商暫緩回應與速率限制在 API 規模下很常見。免費郵箱驗證 API 對這些情況回傳 unknown，不會將其誤判為 deliverable 或 invalid。
重試邏輯應寫在你的程式碼裡，而不是藏在端點內部。一個默默猜結果的 API 會拿走你判斷該重試還是轉人工複核所需的唯一訊號。
響應欄位
把每個驗證 API 狀態對應到應用決策
API 響應設計成可以直接按狀態分支。每個狀態對應一個動作，API 原因碼解釋臨界情況。
deliverable — 放行
呼叫時收件路徑接受了探測。可以接受註冊、寫入聯絡人，或把郵件排入佇列——仍須遵守你產品自己的同意規則。
免費郵箱驗證 API 在免費方案與付費量級上回傳同一狀態欄位，因此你用免費積分測到的行為，就是上線後的行為。
undeliverable — 拒絕或再問一次
API 回傳永久失敗，代表該地址會硬退信。在註冊表單中，顯示 API 原因碼並請使用者重新輸入。在後台任務中，將該記錄排除，而不是刪除原始值。
永遠不要自動糾正域名。驗證 API 能告訴你某個地址失敗；它不能告訴你對方本意是哪個地址。
risky — 套用你自己的策略
Risky 代表郵箱可能接收郵件，但同時帶有產品可能在意的標誌。請查看原因碼：付費註冊使用一次性郵箱，與支援表單填入角色地址，是兩種完全不同的問題。
只需在呼叫我們免費郵箱驗證 API 的位置實作一次策略，產品內每個介面就會用相同方式處理同一個 API 標誌。
unknown — 重試，不要丟棄
接收服務商給 API 的回答什麼也證明不了。把該地址排隊等待稍後的 API 呼叫，而不是攔住使用者，或把假陰性寫入資料庫。
用在註冊流程裡的即時郵箱驗證 API 在這裡應優雅降級：先放使用者透過，再非同步驗證一次，並按第二次 API 結果行動。
整合模式
在真實系統裡該把郵箱驗證 API 接到哪裡
多數 API 整合使用同樣三個觸點。把 API 呼叫放對位置，比選哪個 SDK 更重要。
- 1
在採集那一刻
提交地址時呼叫 API——例如註冊、結帳、線索表單或更新個人資料。趁使用者仍在頁面上時驗證，才有機會讓本人修正輸入錯誤；這是在表單內即時呼叫 API 的最有力理由。
只允許短時間等待，逾時後不要繼續阻塞流程。免費郵箱驗證 API 的響應通常在一至三秒內回傳，但表單不該因接收服務商回應緩慢而失敗。
- 2
在既有資料管線中
CRM 同步任務、資料富化 worker 與 ETL 步驟，都是這套免費郵箱驗證 API 適合的接入點。將 API 呼叫加入記錄既有的流轉位置，並將狀態、標誌與 checked-at 時間戳記存為欄位。
面對檔案而不是單條記錄時，POST /verify/file API 接受 CSV 或 Excel，並在任務完成時呼叫你的 webhook，因此批量 API 工作不需要長連線。
- 3
在 AI 智慧體與工具內部
MCP Server 讓 Claude Desktop 與 Cursor 能以自然語言使用我們的免費郵箱驗證 API，Agent Skills 則可一鍵安裝到智慧體平臺。兩條路徑都回傳與 REST API 相同的結構化 JSON。
這對智慧體可靠性很重要：模型不必解析敘述文字，且當底層 API 回傳 unknown 時，工具也不能聲稱地址沒問題。
- 4
就在傳送前後
資料新鮮度比驗證量更重要。應在接近傳送時再驗證高價值收件人，而不是信任幾個月前寫下的狀態；休眠記錄進入郵件活動前也要重新驗證。
對於整份名單， 批量郵箱驗證 在檔案上執行同一引擎，這樣你就不必在即時端點之上重寫批處理邏輯。
如實邊界
郵箱驗證 API 不會聲稱的四件事
API 響應可信，是因為它的範圍很窄。下面每一項都屬於別的工具或別的團隊，而不屬於驗證 API。
它不證明身份或同意
一個會收信的郵箱，說明不了誰在控制它、他們在哪工作，或是否同意被聯絡。共享別名、轉發地址與過期富化資料，都會產出貼在錯誤的人身上的 deliverable API 結果。
使用第一方資料確認身份，並在你自己的權威資料系統中記錄同意狀態。任何驗證 API 都無法提供這兩者。
它不保證進入收件箱
SMTP 接受描述的是 API 呼叫那一刻的收件路徑。活動能否進入收件箱，取決於發件人聲譽、認證、內容與投訴歷史——這些都是 API 從未觀察的發件側因素。
驗證去掉的是地址級失敗。郵件本身的送達率是另一套工作，用另一套指標。
Catch-All 域名仍然不確定
Catch-All 域名接受每一個 local part，因此沒有免費郵箱驗證 API 能證明某個猜出來的地址真的存在。API 回傳該標誌，正是為了讓你的程式碼不必去推斷。
將 Catch-All 結果交由複核，不要直接歸類為 deliverable，尤其是按姓名模式拼出來的 B2B 名單。
結果是帶時間戳的一次觀察
每天都有郵箱被關閉、別名被停用、域名被遷移。API 報告的是呼叫期間為真的事實，而該事實從 API 響應的那一秒就開始變舊。
把 checked-at 時間存在狀態旁邊，好讓下游系統判斷證據何時已經太舊、不能據此行動。
相關入口
驗證 API 與平臺其餘部分的關係
同一引擎透過多個 API 入口暴露。選對入口通常取決於誰在問，而不是準確率。
單一地址，手動檢查
當需要檢視單條結果、而不是自動化處理成千上萬條時， 郵箱驗證器 在瀏覽器中執行同一條 SMTP 流水線，並展示 API 會回傳的每一項標誌。
這是在開始串接郵箱驗證 API 前，最快的地址合理性檢查方式。
一次處理整份檔案
當工作對象是整份名單而不是資料流時， 郵箱清單清洗 對每一行應用同一套規則，並在匯出中保留原因。
檔案與 API 呼叫共用一個引擎，因此批量清洗的一行與透過驗證 API 檢查的一個地址不會互相矛盾。
以校驗為先的表述
郵箱校驗 API 頁面為那些搜尋校驗而非驗證的團隊描述同一端點，並從該角度寫整合細節。
端點、schema 與 SMTP 證據完全相同；不同的只是文件的表述角度。
常見問題
1. 郵箱驗證 API 有多快？
快取的 API 結果在 200ms 內回傳。完整 SMTP 驗證平均 1–3 秒完成，因此可以在表單裡當作即時郵箱驗證 API 使用。該 API 支援每分鐘最多 6,000 次單封驗證請求與 1,500 次批量請求。
2. 如何整合郵箱驗證 API？
驗證 API 使用標準 REST 呼叫與 JSON 響應。提供 Python、Node.js、Go 與 PHP 官方 SDK。多數 API 整合可在 30 分鐘內完成。MCP Server 與 Agent Skills 完全無需程式碼——安裝一次，即時郵箱驗證 API 即可在任何支援的 AI 客戶端中使用。
3. 郵箱驗證 API 如何收費？
Starter 方案 $20 購買 20,000 積分，單價 $0.001 / 郵箱——無月費，按用量付費。量大可低至 1M 積分時 $0.00035 / 郵箱。免費郵箱驗證 API 方案每天登入提供 20 個免費積分，每月最多 600 個，無需信用卡。
4. 每次驗證 API 響應包含什麼？
每次 API 響應包含驗證狀態（deliverable、undeliverable、risky 或 unknown）、0–100 的品質評分、風險等級與原因碼。還包含一次性郵箱標誌、角色帳號標誌、Catch-All 檢測，以及拼寫糾錯建議。
5. 驗證 API 安全嗎？
所有 API 請求使用 HTTPS。每次 API 呼叫都需要 API 金鑰認證，並可啟用 IP 白名單以增強安全。BillionVerify 完全符合 GDPR 與 CCPA，處理後自動刪除資料。
6. AI 智慧體與 LLM 如何使用此驗證 API？
AI 智慧體可透過 MCP Server（Claude 與 Cursor 中的自然語言）、預建 Agent Skills（Claude 與 Manus 一鍵安裝），或從 LangChain、CrewAI 或任意 Anthropic / OpenAI SDK 直接 REST 呼叫。每條路徑都打到同一郵箱驗證 API，並回傳相同的結構化 JSON——無需響應轉換。
7. 郵箱校驗 API 與郵箱驗證 API 有什麼區別？
郵箱校驗 API 與郵箱驗證 API 通常指同一端點——檢查地址是否真實、可送達。BillionVerify 使用 SMTP 級驗證，確認接收伺服器上郵箱存在，而不是僅做 DNS 或語法校驗。單一 /verify 端點在一個 JSON 響應中回傳狀態、品質評分、一次性標誌、角色帳號標誌與 Catch-All 檢測。
郵箱驗證 API
取得你的 API 金鑰
一個端點覆蓋全部驗證類型。包含 MCP Server 與 Agent Skills。免費郵箱驗證 API 方案每天登入提供 20 個積分，每月最多 600 個，無需信用卡。
每月 600 點免費積分 · 原生 MCP Server 集成 · 無需信用卡
99.9%
準確率
Real-time
API 速度
$0.00014
每封郵件
600/mo
永久免費