API Pemeriksa Email: Memilih Antara Permintaan Tunggal, Multi, dan Massal

Cara memilih permintaan API pemeriksa email yang tepat untuk setiap pekerjaan dan memetakan hasil dapat dikirimi, tidak dapat dikirimi, dan tidak dapat ditentukan ke dalam kode.

API pemeriksa email harus dipanggil dalam salah satu dari tiga bentuk, yang dipilih berdasarkan siapa yang menunggu dan berapa banyak alamat yang Anda miliki. Gunakan pemeriksaan tunggal (POST /api/v1/check) saat seseorang menunggu satu alamat, pemeriksaan multi-alamat sinkron (POST /api/v1/batch-check, 1–100 alamat, hasil sesuai urutan input) saat sekelompok kecil alamat tiba bersamaan, dan tugas massal asinkron (POST /api/v1/bulk-tasks, lalu polling status) saat alamat sudah tersimpan dalam sebuah file. Apa pun bentuknya, rancang kode Anda berdasarkan tiga hasil alih-alih bendera ya/tidak: dapat dikirimi, tidak dapat dikirimi, dan tidak dapat ditentukan, dengan input yang salah format ditangani sebelum panggilan dilakukan. Setiap hasil yang selesai hanya mendeskripsikan alamat pada saat pemeriksaan dilakukan.

Apa yang dijawab oleh API pemeriksa email, dan apa yang menjadi tanggung jawab Anda

Sebagian besar halaman yang memberi peringkat untuk topik ini hanya mencantumkan fitur dan berhenti di situ. Pertanyaan integrasinya lebih sempit: apa yang sebenarnya diputuskan oleh satu panggilan, dan apa yang masih menjadi tanggung jawab aplikasi Anda?

Pemeriksaan Keterkiriman Email dari EmailCheckPro mengembalikan hasil selesai berupa dapat dikirimi (alamat dapat menerima email pada saat pemeriksaan) atau tidak dapat dikirimi. Pemeriksaan Avatar Email menambahkan sinyal avatar publik, tetapi hanya untuk alamat Gmail, Yandex, dan Mail.ru.

Aplikasi Anda masih memiliki tiga tugas:

• Penyaringan format. Alamat yang lengkap memiliki bagian lokal, tanda @, dan domain. Input yang salah format adalah kesalahan formulir, bukan vonis tidak dapat dikirimi, jadi tangkaplah sebelum menghabiskan panggilan.
• Tautan konfirmasi atau catatan persetujuan Anda sendiri mencakup hal tersebut.
• Waktu. Hasil adalah milik saat pemeriksaan dilakukan. Simpan tanggal di samping hasil agar pekerjaan selanjutnya mengetahui seberapa lama hasil tersebut.

Menjaga batasan ini dalam kode, bukan hanya dalam dokumentasi, akan menghindari bug integrasi paling umum yang dijelaskan di bawah ini.

Memilih bentuk permintaan API pemeriksa email

Ketiga bentuk permintaan tersebut tidak dapat dipertukarkan, dan memilih bentuk yang salah adalah penyebab umum formulir lambat atau pekerjaan impor yang rapuh.

Cara cepat untuk memutuskan:

1. Apakah ada seseorang yang menunggu di layar? Gunakan endpoint tunggal hanya untuk alamat yang mereka ketik.
2. Apakah alamat tiba bersamaan dan jumlahnya pas dalam 100? Kirim satu permintaan multi. Ini tetap sinkron: panggilan tunggal yang lebih besar, bukan tugas massal kecil.
3. Apakah sumbernya sudah berupa file, atau jauh melebihi beberapa ratus baris? Kirimkan tugas massal dan biarkan pekerja latar belakang mengumpulkan hasilnya. Batas tugas per produk berlaku dan tercantum dalam dokumentasi API.
4. Apakah pekerjaan membutuhkan avatar? Filter daftar ke domain Gmail, Yandex, dan Mail.ru yang didukung terlebih dahulu. Domain yang tidak didukung akan ditolak sebelum dikenakan biaya waktu nyata, dan dalam file massal avatar, hal ini akan menyebabkan persiapan gagal, dengan reservasi dikembalikan.

Untuk beberapa ratus alamat yang tidak ada dalam file, baik beberapa permintaan multi atau pemeriksaan waktu nyata di dasbor, yang menangani hingga 500 alamat, adalah pilihan yang wajar.

Memetakan hasil ke dalam logika aplikasi

Menggabungkan hasil menjadi boolean adalah tempat di mana sebagian besar integrasi salah. Tipe status kecil menjaga makna tetap utuh:

Tiga aturan mengikuti dokumentasi:

• Dalam pemeriksaan waktu nyata tunggal, alamat yang tidak dapat ditentukan mengembalikan kode bisnis alih-alih hasil dan tidak dikenakan biaya. Perlakukan cabang tersebut sebagai statusnya sendiri, bukan sebagai kesalahan untuk dicoba ulang dalam loop yang ketat.
• Dalam respons multi, setiap item menyatakan apakah hasil selesai ada. Hanya item dengan hasil yang membawa status dapat dikirimi atau tidak dapat dikirimi; sisanya termasuk dalam cabang tidak dapat ditentukan atau tidak selesai.
• Pemeriksaan yang tidak valid, gagal, dan tidak dapat ditentukan tidak dikenakan biaya, jadi mencoba ulang nanti tidak memakan biaya apa pun selain waktu. Jadwalkan percobaan ulang alih-alih mengulanginya segera.

Menjalankan tugas massal asinkron tanpa kejutan

Tugas massal adalah mesin status kecil, dan tugas ini harus berada di pekerja latar belakang alih-alih permintaan web.

1. Siapkan file. Tulis TXT atau CSV dengan satu alamat email lengkap per baris. Baris yang tidak valid dan duplikat dihapus selama persiapan, tetapi menghapus sampah yang jelas terlebih dahulu membuat hitungan Anda sendiri lebih mudah direkonsiliasi.
2. Kirim dan rekam. Simpan referensi tugas yang dikembalikan oleh POST /api/v1/bulk-tasks di database Anda, bersama dengan nama file sumber, produk yang digunakan, dan waktu pengiriman. Pekerja yang mengalami crash kemudian dapat melanjutkan alih-alih mengirim ulang.
3. Polling dengan sabar. Kueri GET /api/v1/bulk-tasks/{id} tidak lebih sering dari setiap 30 detik. Pekerjaan terjadwal yang memeriksa sekali dan tidur lebih cocok daripada loop yang membiarkan koneksi terbuka.
4. Unduh dengan segera. Tugas yang berhasil menyediakan satu CSV di tautan unduhan yang bertahan selama 12 jam. Jika tautan kedaluwarsa, kueri tugas yang sama lagi untuk mendapatkan tautan baru alih-alih mengunggah file untuk kedua kalinya.
5. Gabungkan berdasarkan alamat. Karena persiapan dapat menghapus baris, gabungkan CSV hasil kembali ke catatan Anda berdasarkan alamat email, jangan pernah berdasarkan nomor baris.

CSV keterkiriman memasangkan setiap alamat dengan hasilnya. CSV avatar juga menyatakan apakah avatar publik ditemukan dan memberikan tautan avatar, yang bisa kosong bahkan ketika avatar ada, jadi perlakukan tautan kosong sebagai nilai normal.

Mengoperasikan integrasi sehari-hari

Setelah bentuk permintaan dan status sudah tepat, beberapa kebiasaan operasional menjaga integrasi tetap tenang:

• Hanya kunci sisi server. Kunci API menghabiskan saldo akun, yang digunakan bersama oleh pemeriksaan web, panggilan REST, tugas massal, dan akses MCP. Jangan pernah mengirimkannya dalam kode browser atau seluler.
• Periksa pada titik perubahan. Periksa saat alamat dibuat atau diedit, lalu gunakan kembali hasil yang disimpan dalam jendela pemeriksaan ulang Anda sendiri alih-alih memanggil pada setiap tampilan halaman.
• Gagal terbuka di formulir, tertutup di jalur pipa. Jika pemeriksaan lambat atau tidak selesai selama pendaftaran, biarkan orang tersebut melanjutkan dengan alamat yang ditandai. Dalam jalur pengiriman, tahan baris yang ditandai sampai mereka memiliki hasil selesai.
• Lindungi endpoint Anda sendiri. Jika aplikasi Anda mengekspos rute "periksa alamat ini", batasi kecepatannya dan kembalikan pesan yang konsisten. Panduan validasi email OWASP memperingatkan agar tidak membiarkan formulir mengungkapkan apakah suatu akun ada.
• Berikan klien AI endpoint MCP. https://emailcheckpro.com/mcp mendukung pemeriksaan tunggal, hingga 100 alamat per panggilan, daftar produk, dan kueri saldo. Pekerjaan massal berbasis file tetap berada di alur kerja web atau API REST.

Batas permintaan dan detail penggunaan saat ini diterbitkan dalam dokumentasi API EmailCheckPro; bacalah di sana alih-alih membuat asumsi yang dikodekan secara permanen.

Pemeriksaan format yang sesuai dengan ekspektasi API

Panggilan termurah adalah panggilan yang tidak pernah Anda buat untuk input yang salah format. Dua referensi membantu Anda memilih layar yang masuk akal:

• Standar WHATWG HTML mendefinisikan pola yang digunakan browser untuk bidang type="email". Standar ini sengaja menyimpang dari standar surat lengkap agar tetap praktis, yang menjadikannya dasar sisi server yang masuk akal juga.
• RFC 5321 menjelaskan bentuk alamat yang digunakan dalam transportasi surat. Perlakukan ini sebagai referensi format untuk kasus khusus seperti bagian lokal yang dikutip, bukan sebagai deskripsi tentang cara kerja layanan pemeriksaan apa pun.

Dalam praktiknya: pangkas spasi putih, hapus tanda baca di akhir yang disalin dari dokumen, gunakan huruf kecil untuk domain, pertahankan bagian lokal seperti yang dimasukkan, dan tolak hanya input yang jelas-jelas tidak memiliki bagian lokal, @, atau domain. Pola yang terlalu ketat yang menolak tanda tambah atau domain tingkat atas yang panjang akan menolak pengguna nyata dan harus dihindari.

FAQ

Kapan tim harus beralih dari panggilan multi-alamat ke tugas massal?

Beralihlah saat alamat sudah ada dalam file, atau saat pekerjaan membutuhkan banyak panggilan multi berturut-turut hanya untuk menyelesaikan daftar. Permintaan multi cocok untuk grup hingga 100 yang tiba bersamaan dan membutuhkan jawaban dalam respons yang sama. Tugas massal cocok untuk ekspor yang disiapkan yang dapat menunggu, karena hasil tiba nanti sebagai satu CSV dan pekerja hanya perlu melakukan polling status setiap 30 detik atau lebih jarang.

Bagaimana aplikasi harus menyimpan hasil API pemeriksa email?

Simpan alamat seperti yang dimasukkan, produk yang digunakan, hasil dalam kata-kata biasa, tanggal pemeriksaan, dan sumber alamat. Catatan itu memungkinkan dukungan menjelaskan keputusan, memungkinkan pekerjaan pemeriksaan ulang memilih hasil terlama terlebih dahulu, dan menjaga baris yang tidak dapat ditentukan atau tidak selesai terpisah dari yang tidak dapat dikirimi. Hindari menyimpan payload respons mentah sebagai satu-satunya catatan, karena sistem lain kemudian akan bergantung pada format API.

Bisakah hasil dapat dikirimi menggantikan email konfirmasi?

Tidak. Hasil dapat dikirimi menginformasikan apakah alamat dapat menerima email pada saat pemeriksaan, dan pemeriksaan itu sendiri tidak mengirim apa pun. Tautan konfirmasi menjawab pertanyaan yang berbeda: apakah orang yang memasukkan alamat tersebut mengendalikannya dan setuju untuk menerima pesan. Banyak alur pendaftaran menggunakan pemeriksaan untuk menangkap alamat mati sebelum mengirim, lalu mengandalkan konfirmasi untuk persetujuan dan kepemilikan.

Apa cara teraman untuk mencoba ulang pemeriksaan yang tidak selesai?

Masukkan ke dalam antrean dengan penundaan alih-alih mencoba ulang dalam permintaan yang gagal. Pemeriksaan yang tidak dapat ditentukan, gagal, dan tidak valid tidak dikenakan biaya, tetapi percobaan ulang segera jarang mengubah hasil dan dapat memperlambat layanan Anda sendiri. Percobaan ulang terjadwal, dengan batas upaya dan catatan tanggal setiap upaya, menjaga catatan tetap jujur dan memungkinkan peninjau melihat alamat mana yang masih belum memiliki hasil selesai.

Pelajari Lebih Lanjut

Pilih informasi produk yang sesuai dengan langkah selanjutnya dalam alur kerja Anda.

• Lihat dokumentasi produk →
• Bicara dengan tim →