Panduan produk
Cara Merencanakan Alur Kerja API Verifikasi Nomor Telepon Massal
Pelajari cara merencanakan alur kerja API verifikasi nomor telepon massal dengan pemeriksaan batch sinkron, format E.164, dan sinyal pendaftaran platform.

Panduan teknis untuk merencanakan alur kerja API verifikasi nomor telepon massal menggunakan endpoint batch sinkron, format E.164, dan sinyal keberadaan akun WhatsApp.
Merencanakan alur kerja API verifikasi nomor telepon massal yang efisien memerlukan penyusunan permintaan klien di sekitar endpoint batch sinkron, penerapan format nomor E.164, dan penguraian sinyal keberadaan akun dengan benar. Dengan WA Lookup, sistem mengirim hingga 100 identifier dalam satu permintaan HTTP sinkron dan menerima keluaran verifikasi langsung di dalam respons permintaan tersebut. Karena permintaan dijalankan secara sinkron tanpa polling tugas, webhook, atau penundaan antrean latar belakang, aplikasi klien harus menangani konkurensi, batas waktu, serta keberhasilan atau kegagalan tingkat batch secara real-time untuk mendukung perutean hilir dan segmentasi pelanggan.
Memahami Arsitektur Batch Sinkron
Merancang pipeline verifikasi otomatis dimulai dengan memahami bagaimana data berpindah antara layanan internal Anda dan endpoint verifikasi. Banyak sistem perusahaan mengharapkan pemrosesan batch asinkron yang melibatkan antrean worker latar belakang, polling status, atau listener webhook. Sebaliknya, WA Lookup menerapkan model permintaan-respons sinkron untuk pemeriksaan tunggal maupun operasi batch. Dalam model ini, aplikasi klien Anda memulai permintaan HTTP POST dan menerima data verifikasi yang sudah selesai langsung di dalam body respons. Endpoint batch menerima hingga 100 nomor telepon dalam satu payload. Pemrosesan berlangsung selama permintaan berjalan, mengembalikan hasil untuk seluruh kumpulan atau menggagalkan batch secara keseluruhan. Hal ini menghilangkan beban operasional untuk melacak ID job, menyimpan status job sementara di basis data, atau mengelola infrastruktur listener webhook. Karena respons dikembalikan secara sinkron, tim engineering harus mengonfigurasi klien HTTP aplikasi mereka dengan tepat. Pengaturan batas waktu permintaan harus mengakomodasi waktu yang diperlukan untuk mengevaluasi hingga 100 identifier. Alih-alih menerapkan tingkatan pembatasan laju berdasarkan kuota per menit yang arbitrer, tim sebaiknya merancang pool koneksi sisi klien berdasarkan kontrol konkurensi per pengguna dan kebijakan batas waktu yang terdokumentasi dalam dokumentasi API resmi.
Menyiapkan dan Menormalkan Nomor Telepon
Pipeline verifikasi yang tangguh memerlukan kebersihan data yang ketat di sisi klien sebelum data mencapai lapisan jaringan. API verifikasi mewajibkan setiap nomor telepon yang dikirim mengikuti standar internasional E.164. Mengirim nomor yang tidak diformat, diformat secara lokal, atau cacat akan menyebabkan kesalahan validasi atau hasil yang tidak dapat ditentukan. Format E.164 menstandarkan nomor telepon menjadi satu string yang berisi tanda plus di depan, kode panggilan negara, dan nomor pelanggan nasional tanpa spasi, tanda hubung, tanda kurung, atau prefiks seperti angka nol trunk. Pipeline klien sebaiknya menjalankan normalisasi sebagai langkah praproses otomatis:
- Hapus karakter non-angka seperti tanda baca, spasi, dan simbol format.
- Tentukan kode negara yang dimaksud berdasarkan metadata negara atau kolom masukan pengguna.
- Hapus prefiks lokal, seperti angka nol di depan yang umum digunakan dalam panggilan domestik.
- Tambahkan kode panggilan negara internasional dan simbol plus di depan.
- Validasi panjang string terhadap spesifikasi standar negara sebelum dibuat batch.
Setelah dinormalkan, bagi data Anda ke dalam batch terpisah yang masing-masing berisi tidak lebih dari 100 identifier per payload. Menjaga ukuran batch pada atau di bawah batas ini memastikan kompatibilitas dengan kontrak endpoint batch.
Memilih Kemampuan Pemeriksaan yang Tepat
Alur kerja verifikasi melayani fungsi bisnis yang berbeda, mulai dari pembersihan daftar kontak operasional hingga perutean penjualan yang diperkaya. WA Lookup menyediakan tiga kemampuan pemeriksaan yang berbeda melalui parameter service_type, sehingga tim hanya meminta titik data yang diperlukan untuk alur kerja mereka:
| Jenis Layanan | Cakupan & Sinyal Akun yang Dikembalikan | Penerapan Utama dalam Alur Kerja |
|---|---|---|
ws |
Pemeriksaan pendaftaran platform dasar yang mengembalikan status registered. |
Pembersihan daftar bervolume tinggi dan verifikasi keterjangkauan. |
ws_avatar |
Pemeriksaan pendaftaran platform yang mengembalikan registered, keberadaan avatar, dan avatar_url. |
Pengayaan prospek, validasi visual, dan pemeriksaan kelengkapan profil. |
ws_business |
Pemeriksaan pendaftaran platform yang mengembalikan registered dan klasifikasi akun business. |
Memisahkan nomor bisnis komersial dari akun pribadi standar. |
Memilih kemampuan yang tepat membantu sistem meminimalkan beban pemrosesan payload. Untuk penyaringan bervolume tinggi ketika tim hanya perlu mengetahui apakah suatu identifier terdaftar di WhatsApp, pemeriksaan standar ws memberikan indikator keterjangkauan yang efisien. Untuk alur kerja CRM yang memprioritaskan kualitas prospek atau kategorisasi komersial, ws_business memberikan konteks perutean yang berharga dengan mengidentifikasi apakah akun tersebut beroperasi sebagai entitas WhatsApp Business resmi.
Menangani Respons API dan Kondisi Kesalahan
Integrasi yang tangguh memerlukan penguraian payload respons yang deterministik dan penanganan kesalahan yang andal. Permintaan yang selesai mengembalikan envelope JSON standar yang terdiri dari kolom code, msg, dan data. Untuk pemeriksaan yang selesai, objek data berisi service_type, identifier, dan nilai boolean registered. Saat mengurai objek keluaran, sistem harus menangani representasi status dengan tepat:
- Penentuan Berhasil: Pemeriksaan yang selesai memberikan
registered: trueatauregistered: false. Saat menggunakanws_avatar, respons juga menyertakan booleanavatardanavatar_url(yang dapat berupa string kosong). Saat menggunakanws_business, respons menyertakan booleanbusiness. - Hasil Tidak Dapat Ditentukan: Jika suatu identifier tidak dapat diputuskan secara pasti pada saat pemeriksaan, API mengembalikan kode bisnis bukan nol, bukan objek hasil selesai dengan nilai null. Aplikasi klien sebaiknya memeriksa kolom
codetingkat atas sebelum mencoba mengurai propertidata. - Penagihan dan Pengembalian Dana: Penagihan berlaku per pemeriksaan. Setiap kali pemeriksaan gagal atau berakhir dengan status tidak dapat ditentukan, platform secara otomatis mengembalikan saldo terkait ke akun. Layanan hilir sebaiknya hanya mengandalkan kolom respons publik yang terdokumentasi.
Menerjemahkan Sinyal Keberadaan Akun ke dalam Logika Bisnis
Fase akhir alur kerja verifikasi massal melibatkan penyaluran data terverifikasi ke perutean internal, sistem CRM, atau mesin pengiriman komunikasi. Untuk menjaga integritas data, tim harus menafsirkan dengan akurat apa yang diwakili oleh sinyal pendaftaran platform. Sinyal ini memastikan bahwa identifier tersebut terdaftar di platform. Organisasi sebaiknya menggunakan hasil pendaftaran sebagai masukan pendukung keputusan di samping data operasional yang sudah ada. Misalnya, platform pemasaran dan dukungan dapat menggunakan sinyal keterjangkauan untuk merutekan pesan ke WhatsApp bagi nomor yang terdaftar sambil mengarahkan kontak yang tidak terdaftar ke saluran komunikasi alternatif seperti SMS atau email. Memasukkan sinyal terverifikasi ini membantu tim mengoptimalkan sumber daya operasional, mengurangi upaya pengiriman pesan yang gagal, dan menjaga repositori kontak tetap teratur.
FAQ
Apakah API verifikasi massal mendukung antrean asinkron atau webhook?
Tidak. API verifikasi beroperasi dengan arsitektur permintaan-respons sinkron. Setiap permintaan—baik memeriksa satu identifier maupun batch hingga 100 nomor—mengembalikan hasil lengkapnya dalam respons HTTP permintaan tersebut. API ini tidak menggunakan token pengiriman tugas, loop polling, callback webhook, atau ekspor file yang dapat diunduh.
Apa yang terjadi jika suatu identifier dalam batch tidak dapat diproses?
Endpoint batch sinkron memproses kiriman sebagai satu unit atomik: endpoint mengembalikan seluruh batch atau gagal secara keseluruhan. Jika pemeriksaan individual tidak dapat diputuskan, API mengembalikan kode bisnis bukan nol, bukan objek hasil yang tidak lengkap, dan pemeriksaan yang tidak dapat ditentukan atau gagal dikembalikan dananya secara otomatis.
Bisakah sistem menggunakan kredensial yang sama untuk pemeriksaan nomor tunggal dan batch?
Ya. Sistem klien mengautentikasi permintaan nomor tunggal maupun permintaan batch menggunakan header X-API-Key yang sama. Saldo akun bersama, kontrol konkurensi, dan dasbor pelaporan berlaku untuk semua metode verifikasi.
Pelajari Lebih Lanjut
Pilih informasi produk yang sesuai dengan langkah berikutnya dalam alur kerja Anda.