電子郵件驗證 API
一個端點覆蓋所有驗證類型。即時郵箱驗證 API，含 SMTP 檢查、結構化 JSON 響應，以及原生 MCP 與 Agent Skills 整合。
全部驗證 API 模式，同一端點
每種驗證類型都可透過同一 REST 郵箱驗證 API 存取。
單一郵件驗證
POST /verify — 一次即時郵箱驗證 API 呼叫，響應時間低於 3 秒。在一個 JSON 物件中回傳狀態、可投遞性、品質評分和風險標記。
批次驗證
POST /verify/bulk — 每次 API 呼叫同步驗證最多 50 個地址。全部結果在同一次 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 響應提供的資訊多於它所取代的布林值時，這項升級才划算。
status 才是程式碼應分支的欄位
API 會回傳四種狀態之一：deliverable、undeliverable、risky 或 unknown。這四種狀態反映真實情況；任何將它們壓縮為 true 和 false 的驗證 API，都會迫使呼叫方自行補回遺失的細微差別。
先依 status 分支。免費郵箱驗證 API 響應中的其他欄位用來說明該狀態，而不是取代它。
score 和風險等級用於排序，不是用於設門檻
0 到 100 的品質評分和風險等級，可用來排列佇列、決定銷售跟進優先順序，或依使用情境調整閾值。它們是衍生的 API 欄位，應視為排序提示，而不是 API 裁決。
只靠評分設門檻，團隊很容易誤拒好客戶。用 status 做門檻，用 score 做排序。
reason code 讓 API 可除錯
每個非 deliverable 的 API 回應都附有機器可讀的原因。語法無效、沒有郵件路由、郵箱遭拒和服務供應商延遲，各是不同的問題，也有不同的修正方式；我們的免費郵箱驗證 API 會逐一標明，而不是只回傳籠統的失敗。
記錄 API 的 reason code，而不是說明文字。reason code 跨版本保持穩定，讓團隊在幾個月後仍能回答特定地址的支援問題。
布林標記描述的是地址本身，不是它的可投遞性
一次性郵箱、角色帳號、Catch-All 和免費個人 webmail，以彼此獨立的 API 標記回傳。一個地址完全可投遞，同時帶上其中三項，完全可能——這正是語法校驗器表達不了、而 API 可以表達的情況。
這就是即時郵箱驗證 API 和格式檢查的實際差別：格式檢查告訴你字串形狀正確，API 告訴你這個地址實際是什麼。
遷移
從語法校驗器遷到真正的驗證 API
團隊通常已在程式碼中使用正規表示式或函式庫呼叫，才會走到這一步。API 遷移本身不大，但有三個習慣必須一起改變。
別再把格式當成答案
正規表示式只能證明字串可能是地址。這套免費郵箱驗證 API 證明的是郵件伺服器目前會接收它。客戶端可保留正規表示式作為低成本提示，但不要再讓它決定一筆記錄是否有效。
在程式碼中，這表示刪除「格式有效，所以儲存」的分支，改為依 API 的 status 欄位分支。
給 API 設超時和回退
接收方服務供應商回應緩慢時，網路呼叫也會變慢。為 API 設定表單可接受的逾時時間，並事先決定逾時後的處理方式：通常是接受該地址、標為未驗證，再於稍後透過另一次 API 呼叫重新檢查。
即時郵箱驗證 API 絕不該成為註冊失敗的原因。降級到未驗證，而不是拒絕。
把結果存成資料，而不是過濾器
將 API 的 status、reason code、標記和 checked-at 時間戳寫入記錄。若只儲存處理後的布林值，經過三次行銷活動後，團隊將無法解釋為何抑制該地址，也無法區分最新與過期的 API 證據。
存下完整 API 響應，還可以改策略而不必重新驗證：事實留著，變的只是讀取它們的規則。
認真處理 unknown，而且只定一次
unknown 不是 API 錯誤，也不是失敗。它表示接收方服務供應商未給出明確答覆。應在單一位置設定重試策略——佇列、延遲時間、API 最大嘗試次數——避免在程式碼各處加入臨時重試。
多數 unknown 結果會在後續 API 呼叫中得到明確結果，因此我們的免費郵箱驗證 API 會如實回報，而不是猜測。
整合面
呼叫郵箱驗證 API 的四種方式
一個端點，四種 API 使用方式。依工作量和延遲選擇，而不是憑個人偏好。
- 1
單一地址，同步
POST /verify 接收一個地址，並在 1 到 3 秒內回傳完整 JSON。這是註冊表單、結帳和個人資料編輯使用的即時郵箱驗證 API 路徑。
因為這是沒有任務生命週期的單次 API 呼叫，所以也是建立更大型整合前最容易進行對照測試的 API。
- 2
一次呼叫最多 50 個地址
POST /verify/bulk 可同步驗證最多 50 個地址，並以相同 schema 回傳結果。適合頁面或任務每次只需處理少量記錄的情境。
批量上限是硬性 API 邊界，不是軟限制。更大的 payload 會被明確的 API 錯誤拒絕，並指向檔案端點，不會悄悄退化成一次極慢的請求。
- 3
檔案，非同步
POST /verify/file 接受 CSV 或 Excel，在後台處理，並在 API 任務完成時呼叫你的 webhook。大檔案跑著的時候，不必一直佔著連線。
如果工作負載更像名單而不是 API 呼叫， 批量郵箱驗證 會用同一引擎處理上傳檔案，並提供去重和 CSV 匯出。
- 4
從 AI 智慧體和 MCP 客戶端
MCP Server 讓 Claude Desktop 和 Cursor 能以自然語言使用同一套郵箱驗證 API；Agent Skills 則可一鍵安裝至智慧體平臺。兩者回傳的結構化 JSON 與 REST API 完全相同。
這能確保智慧體如實處理結果：工具不能把 unknown 概括為正常，因為智慧體讀取的正是免費郵箱驗證 API 響應。
範圍
驗證 API 故意留給你的部分
這個 API 刻意聚焦於明確範圍。以下每一項都是真實需求——但它們應由系統的其他部分處理，而不屬於驗證 API。
同意與抑制
我們的免費郵箱驗證 API 能告訴你某個地址收不收信。它不能告訴你對方是否同意接收你的郵件，也不會去讀你的抑制名單。
將同意狀態保存在自己的記錄系統中，並在 API 呼叫前檢查，而不是在呼叫後。
身份與在職
一個可投遞的公司地址，並不能證明所指名的人控制該地址，或目前仍在該公司任職。別名、共用收件箱和過期的 enrichment，經常會推翻這項假設。
請以第一方資料確認身份。這套免費郵箱驗證 API 回傳的是郵箱證據，而不是關於某個人的證據。
收件箱投放
SMTP 接受是接收方一側的事實。你的郵件能否進收件箱，取決於寄件者聲譽、認證、內容和投訴歷史，這些 API 都觀察不到。
用 API 修好地址品質；投放問題要靠寄件者側的工作和監控，API 替不了你。
時效
每次 API 響應描述的都是呼叫那一刻。郵箱會關閉、別名會停用、域名會遷移，所以存下來的 API 結果會過期，不管有沒有人再讀它。
依資料變化速度安排複驗週期，並讓 checked-at 時間戳自動決定何時重新驗證。
相關介面
郵箱驗證 API 與其他工具如何配合
同一引擎出現在多個 API 介面背後。選哪一個，取決於誰在問、以及涉及多少地址。
同一端點的 verification 說法
郵箱驗證 API 為搜尋 verification 而非 validation 的團隊說明同一個端點，並更深入解釋 SMTP 證據。
schema、積分和準確率完全相同——只有文件採用的說法不同。
查看單一地址的瀏覽器工具
如果只需要查看單一結果，而不需要任何自動化， 郵箱驗證器 會在瀏覽器中執行相同的驗證流程，並顯示 API 會回傳的每一項標記。
這是在針對免費郵箱驗證 API 編寫程式碼前，確認引擎行為的最快方式。
不做 SMTP 的淺層校驗
如果需求真的只是格式和郵件路由， 郵箱校驗器 只檢查語法和 MX，不會耗用一次 SMTP 檢查。
用它進行低成本預篩，只在退信確實會產生成本的記錄上使用即時郵箱驗證 API。
常見問題
1. 郵箱驗證 API 有多快？
快取的 API 結果在 200ms 內回傳。完整 SMTP 驗證平均 1–3 秒完成，因此可作為表單中的即時郵箱驗證 API。此 API 每分鐘最多支援 6,000 次單次請求和 1,500 次批量請求。
2. 如何整合郵箱驗證 API？
此驗證 API 使用標準 REST 呼叫和 JSON 響應。官方 SDK 支援 Python、Node.js、Go 和 PHP。大多數 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
永久免費