Pembaruan Produk: UX Verifikasi Massal yang Lebih Baik, Kemajuan Async yang Lebih Jujur, dan Model Koneksi MCP Modern

Dalam siklus rilis terakhir, kami melakukan serangkaian perubahan yang semuanya menunjuk ke arah yang sama: membuat BillionVerify lebih mudah dipercaya, lebih mudah dipantau, dan lebih mudah diintegrasikan.

Beberapa perubahan tersebut langsung terlihat dalam produk. Pengalaman Bulk Verify lebih bersih setelah pengiriman file. Halaman riwayat verifikasi lebih berguna saat pekerjaan masih berjalan. Indikator kemajuan sekarang mencerminkan apa yang benar-benar peduli pengguna alih-alih mengekspos mekanik antrian internal.

Beberapa perubahan lebih mendalam. Kontrak status verifikasi di balik UI lebih kaya dan lebih eksplisit. Model data sekarang membedakan antara kemajuan tingkat email dan kemajuan eksekusi backend, yang memberikan klien fondasi yang jauh lebih baik untuk merender status realtime yang jujur.

Dan beberapa perubahan mempengaruhi pengembang secara langsung. BillionVerify MCP sekarang sepenuhnya bergerak menjauh dari setup yang lebih tua ?api_key= dan ke dalam model MCP jarak jauh yang dihosting dan dibangun di sekitar OAuth, penemuan sumber daya yang dilindungi, dan kompatibilitas klien modern. Kami memperbarui produk, dokumen, halaman pemasaran, dan permukaan otentikasi untuk mencerminkan realitas tersebut.

Posting ini menyatukan pembaruan tersebut menjadi satu narasi sehingga pelanggan, pengembang, dan tim internal dapat melihat bagaimana keselarasan mereka.

Jika Anda ingin versi singkatnya, ini dia:

• Verifikasi massal sekarang memiliki alur pasca-unggah yang lebih bersih.
• Pemantauan pekerjaan asinkron lebih informatif dan lebih jujur.
• Antarmuka status backend memiliki struktur yang lebih baik untuk pekerjaan terdistribusi.
• BillionVerify MCP sekarang memiliki bentuk jangka panjang yang lebih jelas: endpoint jarak jauh ditambah OAuth, bukan kunci API yang tertanam dalam URL.

Jika Anda ingin cerita lengkapnya, baca terus.

Tautan Cepat

• Verifikasi email massal
• Apa itu verifikasi email?
• Ringkasan MCP
• Panduan pengembang MCP
• Panduan Claude Code
• Referensi API

Mengapa pembaruan ini saling berkaitan

Pada pandangan pertama, rilis ini terlihat seperti beberapa benang terpisah:

• pembersihan frontend pada halaman verifikasi massal
• layar detail riwayat yang lebih kaya
• peningkatan kontrak status backend
• pembersihan autentikasi dan dokumentasi MCP

Tetapi tema dasar yang sama ada di semuanya: hapus ambiguitas.

Ambiguitas muncul dalam berbagai cara di produk perangkat lunak.

Kadang-kadang terlihat seperti UI duplikat setelah unggahan file. Pengguna tidak yakin tombol mana yang penting, di mana langkah terbaik selanjutnya, atau apakah sistem masih melakukan pekerjaan di latar belakang.

Kadang-kadang terlihat seperti bilah kemajuan yang mengatakan "29% selesai" padahal angka sekitarnya tidak menjelaskan apa yang diwakili persentase tersebut. Apakah 29% email diproses? 29% tugas pekerja selesai? 29% hasil digabungkan? Sebagian besar pengguna tidak ingin mendekode arsitektur antrian hanya untuk memantau pekerjaan.

Kadang-kadang ambiguitas ada dalam onboarding pengembang. Produk mungkin sudah mendukung satu arsitektur dalam produksi sementara bagian dari dokumentasi publik masih menyarankan model koneksi yang lebih lama. Itu menciptakan kegagalan penyiapan, kebingungan, dan ketidakpercayaan yang tidak perlu.

Rilis ini adalah jawaban kami untuk masalah tersebut.

Kami mengencangkan UX produk di sekitar apa yang sebenarnya perlu diketahui pengguna. Kami mengencangkan antarmuka backend di sekitar apa yang sebenarnya perlu dirender klien. Dan kami mengencangkan cerita MCP yang menghadap pengembang di sekitar cara platform bekerja hari ini.

2. Riwayat verifikasi kini berperilaku seperti permukaan pemantauan yang sesungguhnya

Peningkatan besar kedua adalah pada halaman riwayat verifikasi async.

Halaman ini sebelumnya berfungsi, tetapi tipis. Halaman ini dapat menunjukkan bahwa pekerjaan ada dan sedang berlangsung, tetapi belum terasa seperti permukaan yang dirancang untuk pemantauan aktif.

Hal tersebut tidak sesuai untuk pekerjaan verifikasi yang berjalan lama.

Ketika pelanggan membuka halaman detail riwayat saat file masih diproses, mereka tidak hanya mencari angka persentase. Mereka mencoba memahami:

• file apa yang dirujuk pekerjaan ini
• seberapa besar beban kerja
• berapa banyak pekerjaan yang telah selesai
• seperti apa campuran hasil awal
• berapa lama pekerjaan kemungkinan akan selesai

Kami mendesain ulang halaman berdasarkan realitas tersebut.

Metadata stabil kini muncul terlebih dahulu

Halaman riwayat yang diperbarui kini dimulai dengan kartu ringkasan yang stabil. Kartu tersebut menyatukan metadata pekerjaan terpenting:

• nama file asli
• total baris
• jumlah email unik
• perkiraan waktu pemrosesan
• waktu mulai

Informasi ini tidak bergantung pada loop polling realtime. Hal ini penting karena konteks stabil harus muncul secepat mungkin, bahkan jika payload status dinamis masih menetap atau memperbarui.

Ketika pengguna mendarat di halaman, mereka dapat mengorientasikan diri segera alih-alih menunggu respons status langsung untuk melakukan semua pekerjaan.

Area progres langsung jauh lebih kaya

Di bawah ringkasan, pengalaman status berjalan kini jauh lebih baik secara material.

Alih-alih bilah progres kosong dengan konteks terbatas, halaman kini menampilkan:

• volume yang diproses
• volume yang tersisa
• distribusi hasil di seluruh status
• semantik bahasa dan ETA yang sesuai dengan alur verifikasi massal utama

Yang sama pentingnya, halaman menghapus metrik internal yang seharusnya tetap internal. Kami sengaja berhenti mengekspos jumlah tugas-pekerja dan chunk di permukaan yang menghadap pengguna. Nilai-nilai tersebut dapat berguna secara operasional, tetapi bukan yang pelanggan coba ukur ketika mereka bertanya, "Seberapa jauh pekerjaan saya?"

Pertanyaan yang tepat hampir selalu berpusat pada email, bukan berpusat pada antrian.

Alat status selesai tetap utuh

Salah satu batasan desain untuk pekerjaan ini adalah kami tidak ingin kehilangan kedalaman analitis halaman pekerjaan yang selesai.

Jadi kami mempertahankan diagram rincian hasil yang ada dan alat ekspor. Pembaruan ini bukan tentang mengganti pengalaman status selesai. Ini tentang memperkuat bagian atas halaman dan membuat pengalaman status berjalan layak untuk alur kerja.

Itu berarti halaman kini melakukan kedua pekerjaan dengan lebih baik:

• selama pemrosesan, halaman berfungsi sebagai permukaan pemantauan
• setelah selesai, halaman tetap berfungsi sebagai permukaan analisis dan ekspor

Contoh: apa yang kini dapat pengguna pahami sekilas

Halaman pekerjaan yang berjalan kini menjawab semua ini dengan cepat:

• "Ini adalah file 19.293 baris yang saya unggah sebelumnya."
• "Ada 19.010 email unik di dalamnya."
• "Sistem memperkirakan sekitar 33 menit."
• "499 email telah diverifikasi."
• "Sebagian besar set yang selesai sejauh ini valid, dengan bagian tidak valid dan tidak diketahui yang lebih kecil."

Itu adalah model mental yang jauh lebih berguna daripada satu angka persen dengan semantik yang tidak jelas.

3. Semantik Kemajuan Sekarang Lebih Jujur

Salah satu pelajaran terbesar dalam produk asinkron adalah bahwa "kemajuan" bukanlah satu konsep tunggal.

Dalam sistem terdistribusi, ada beberapa hal yang dapat bergerak secara independen:

• tugas worker dapat selesai
• chunks dapat bergabung
• hasil level email dapat terakumulasi
• file akhir dapat menjadi dapat diunduh

Jika klien hanya menerima satu field progress generik, itu harus menebak makna mana dari angka tersebut yang dibawa. Itulah cara Anda berakhir dengan status UI yang secara teknis konsisten tetapi pengalaman pengguna yang membingungkan.

Kami ingin memperbaiki itu di tingkat kontrak.

Pergeseran inti

Antarmuka yang diperbarui membuat dimungkinkan untuk membedakan antara:

• email_progress
• chunk_progress
• progress_source

Perbedaan tersebut memberikan klien basis yang jauh lebih kuat untuk merender kemajuan dengan cara yang sesuai dengan maksud pengguna.

Sebagai contoh:

• bilah kemajuan besar yang menghadap pengguna sekarang dapat memprioritaskan email_progress
• tampilan operasional atau diagnostik masih dapat menggunakan chunk_progress
• jika fallback diperlukan, progress_source dapat membuat itu eksplisit

Ini adalah model yang jauh lebih sehat daripada berpura-pura semua persentase kemajuan berarti hal yang sama.

Contoh payload

Berikut adalah bentuk yang ini memungkinkan:

{
  "task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
  "status": "processing",
  "total_emails": 19010,
  "processed_emails": 499,
  "valid_emails": 496,
  "invalid_emails": 2,
  "unknown_emails": 1,
  "catchall_emails": 0,
  "risky_emails": 0,
  "role_emails": 0,
  "disposable_emails": 0,
  "email_progress": 3,
  "chunk_progress": 7,
  "progress_source": "email_progress"
}

Bahkan tanpa mengetahui apa pun tentang sistem antrian yang mendasar, klien dapat membuat keputusan yang baik dari respons ini.

Itu penting karena API tidak hanya mengembalikan data. Mereka mendefinisikan makna.

Mengapa ini lebih baik untuk pelanggan

Pelanggan tidak peduli apakah worker menyelesaikan 7 dari 96 tugas internal jika hanya 499 dari 19.010 email yang benar-benar telah diproses. Mengekspos abstraksi kemajuan yang salah menciptakan kebingungan, bukan jaminan.

Dengan memindahkan UI utama ke arah email_progress, produk sekarang mencerminkan unit pekerjaan yang pengguna benar-benar pedulikan.

Mengapa ini lebih baik untuk tim frontend

UI tidak lagi harus menyimpulkan terlalu banyak dari satu field persen yang ambigu.

Itu mengurangi seluruh kelas bug produk:

• bilah kemajuan yang tampak terlalu jauh ke depan
• blok ringkasan yang tertinggal di belakang persentase utama
• salinan status yang canggung yang mencoba menjelaskan detail implementasi backend kepada pengguna akhir

Ini juga memberi tim frontend cara yang lebih bersih untuk memisahkan metadata pekerjaan stabil dari data eksekusi yang berubah, yang langsung mengarah ke bagian berikutnya dari rilis.

4. Kontrak status backend sekarang memiliki struktur yang lebih baik untuk pekerjaan terdistribusi

Perubahan frontend tidak akan berfungsi dengan baik tanpa peningkatan kontrak backend.

Kami membuat dua keputusan struktural penting di sini.

Pertama, kami memisahkan metadata stabil dari status live

Beberapa field hampir tidak berubah, jika sama sekali, setelah job dibuat:

• nama file
• waktu pembuatan
• total baris
• jumlah email unik
• perkiraan waktu pemrosesan

Field lain secara inheren dinamis:

• status saat ini
• jumlah email yang diproses
• mix hasil live
• persentase kemajuan

Mencoba memaksa kedua kelas data melalui jalur polling yang sama adalah sumber umum dari ketidaknyamanan UI. Frontend berakhir menunggu data yang seharusnya tersedia segera, sambil juga meminta kembali data stabil lebih sering dari yang diperlukan.

Model baru lebih bersih:

• metadata job stabil diperlakukan sebagai metadata
• status job live diperlakukan sebagai status

Itu terdengar jelas ketika ditulis dengan jelas, tetapi memiliki efek yang bermakna dalam kualitas implementasi.

Halaman detail riwayat sekarang dapat merender informasi ringkasan stabil dengan cepat, melakukan poll hanya pada apa yang perlu berubah, dan menjaga UI tetap tenang saat job berjalan.

Kedua, kami memperluas payload status itu sendiri

Antarmuka status realtime sekarang lebih cocok untuk pemrosesan async terdistribusi karena membawa gambaran yang lebih kaya tentang apa yang telah terjadi sejauh ini.

Itu termasuk counter seperti:

• diproses
• valid
• tidak valid
• tidak diketahui
• berisiko
• catch-all
• role
• disposable
• kredit digunakan

Nilai-nilai tersebut membuat antarmuka lebih berguna tidak hanya untuk permukaan kemajuan yang menghadap pengguna tetapi juga untuk otomasi dan alur kerja hilir. Klien yang memahami mix hasil saat ini dapat membuat keputusan yang lebih baik tentang peringatan, notifikasi, ekspor, dan pasca-pemrosesan.

Contoh: mengapa hal ini penting di luar UI

Bayangkan aplikasi yang menghadap pelanggan yang dibangun di atas BillionVerify yang ingin:

• menampilkan distribusi kualitas live saat daftar berjalan
• memberitahu pengguna jika job menghasilkan tingkat tidak valid yang tidak biasanya tinggi
• menawarkan ekspor terfilter segera setelah set hasil yang berguna ada
• memberdayakan dashboard dukungan atau ops tanpa memerlukan engineering untuk memeriksa status worker mentah

Semua kasus penggunaan tersebut menjadi lebih mudah ketika kontrak status backend eksplisit dan cukup kaya.

Inilah mengapa pekerjaan antarmuka backend penting bahkan ketika perubahan terlihat pertama adalah "progress bar terlihat lebih baik." Progress bar yang lebih baik sering kali merupakan gejala dari kontrak yang lebih baik.

5. MCP kini telah sepenuhnya berpindah ke era OAuth jarak jauh

Bagian utama terakhir dari pembaruan ini adalah menghadap pengembang, namun ini adalah salah satu koreksi produk jangka panjang yang paling penting dalam rilis ini.

BillionVerify MCP kini disajikan dan didokumentasikan dalam bentuk yang seharusnya untuk klien jarak jauh modern:

• endpoint jarak jauh yang dihosting
• otorisasi berbasis OAuth
• penemuan sumber daya terlindungi
• akses token Bearer standar

Endpointnya adalah:

https://mcp.billionverify.com/mcp

Hal ini penting karena pola pengaturan yang lebih lama dapat bertahan dalam materi publik lama setelah platform sudah bergerak maju secara internal. Dalam kasus kami, beberapa dokumen dan permukaan pemasaran masih menyiratkan bahwa MCP dapat dihubungkan melalui kunci API yang tertanam dalam URL dan pembungkus curl --stdio.

Itu bukan lagi bentuk yang tepat untuk BillionVerify MCP.

Model mental yang lama

Pola yang lebih lama terlihat kira-kira seperti ini:

curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"

Model tersebut menggabungkan beberapa kepedulian menjadi satu langkah pengaturan yang canggung:

• transportasi
• autentikasi
• penanganan rahasia
• perilaku pembungkus lokal

Hal ini juga mengirimkan sinyal yang salah tentang bagaimana server MCP jarak jauh yang dihosting harus dikonsumsi oleh klien modern.

Model mental yang baru

Model saat ini lebih bersih.

Untuk Claude Code, pengaturan yang direkomendasikan adalah:

claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp

Kemudian di dalam Claude Code:

/mcp

Dari sana, klien menyelesaikan alur OAuth di browser.

Untuk ChatGPT dan klien MCP jarak jauh lain yang kompatibel, titik awal yang tepat adalah endpointnya sendiri:

https://mcp.billionverify.com/mcp

Klien menemukan metadata sumber daya terlindungi, mengikuti alur otorisasi, dan kemudian menggunakan token akses Bearer untuk panggilan yang diautentikasi.

Perbedaan yang paling penting: auth MCP bukan auth REST

Salah satu alasan dokumen yang lebih lama memerlukan pembersihan adalah kunci API masih penting di BillionVerify. Namun mereka tidak lagi milik cerita bootstrap MCP.

Pemisahan yang bersih adalah:

• REST API menggunakan kunci API
• MCP jarak jauh menggunakan OAuth

Perbedaan tersebut kini jauh lebih jelas di seluruh permukaan produk.

Jika pengembang menggunakan:

• ChatGPT
• Claude Code
• klien MCP jarak jauh lain yang mampu OAuth

mereka harus menggunakan jalur MCP jarak jauh.

Jika mereka sedang membangun:

• otomasi backend-ke-backend
• skrip berbasis kunci API
• klien yang hanya mendukung stdio lokal ditambah kunci API

mereka harus menggunakan referensi API dan alur REST sebagai gantinya.

Ini bukan perbedaan kosmetik. Ini adalah batas produk, dan dokumen harus membuatnya jelas.

6. Dokumentasi publik dan pemasaran sekarang sesuai dengan produk

Upgrade arsitektur hanya menyelesaikan sebagian dari masalah jika materi publik masih menceritakan kisah yang berbeda.

Itulah mengapa kami memperlakukan dokumentasi MCP dan pembersihan pemasaran sebagai bagian dari rilis yang sama.

Kami memperbarui:

• halaman MCP publik
• panduan MCP
• panduan Claude Code
• titik masuk panduan AI
• varian dokumen multibahasa
• salinan FAQ pemasaran terlokalisasi

Tujuannya sederhana: harus ada satu jawaban yang jelas untuk pertanyaan, "Bagaimana cara menghubungkan BillionVerify MCP?"

Sekarang ada.

Mengapa hal ini penting bagi pengembang

Ketika dokumentasi publik tertinggal dari kenyataan implementasi, pengembang membayar harganya dalam tiga cara:

1. Upaya penyiapan yang gagal
2. Kepercayaan yang hilang pada platform
3. Beban dukungan ekstra untuk memperjelas apa yang seharusnya jelas

Dengan menyelaraskan permukaan publik dengan model OAuth jarak jauh aktual, kami mengurangi gesekan yang tidak perlu sebelum menjadi masalah dukungan.

Mengapa hal ini penting untuk positioning platform

Ekosistem MCP bergerak cepat. Seiring lebih banyak tim mengevaluasi alat melalui ChatGPT, Claude Code, dan klien AI lainnya, kualitas pengalaman integrasi pertama menjadi lebih penting.

Produk yang terlihat modern di lapisan protokol tetapi ketinggalan zaman dalam panduan penyiapan publik menciptakan keraguan tepat di mana seharusnya membangun kepercayaan.

Itulah mengapa kami juga memperkuat permukaan sign-in dan consent dengan Terms yang lebih jelas, Privacy, dan visibilitas kontak dukungan. Reviewer, pengembang, dan evaluator enterprise semuanya mendapat manfaat ketika sinyal kepercayaan eksplisit.

7. Pandangan praktis sebelum dan sesudah rilis ini

Salah satu cara berguna untuk memahami rilis adalah dengan membandingkan pengalaman pengguna dan pengembang sebelum dan sesudah.

Sebelum

• File verifikasi massal dapat dikirimkan dengan berhasil, namun status pasca-pengiriman masih memiliki UI duplikat dan langkah berikutnya yang kurang jelas.
• Halaman detail riwayat menampilkan aktivitas, tetapi belum terasa seperti permukaan pemantauan lengkap.
• Nilai persen-selesai dapat ada tanpa dengan jelas memberi tahu pengguna apakah itu mewakili email yang diproses atau penyelesaian tugas internal.
• Materi publik MCP masih sebagian mencerminkan kisah pengaturan ?api_key= warisan.

Sesudah

• Pengalaman pasca-pengiriman lebih bersih, lebih ringkas, dan lebih langsung.
• Kemajuan langsung muncul secara default dalam alur massal.
• CTA utama setelah pengiriman membawa pengguna langsung ke halaman detail pekerjaan yang tepat.
• Halaman detail riwayat menampilkan metadata ringkasan stabil ditambah visibilitas hasil langsung yang lebih kaya.
• Kemajuan menghadap pengguna sekarang berpusat pada semantik kemajuan tingkat email.
• Hitungan tugas internal tidak lagi terbuka sebagai metrik menghadap pelanggan.
• Antarmuka status backend lebih terstruktur dengan baik untuk klien realtime dan pekerjaan terdistribusi.
• Materi publik MCP sekarang konsisten mencerminkan arsitektur OAuth jarak jauh.

Itu bukan satu fitur. Ini adalah lintasan kualitas bermakna di seluruh alur kerja.

8. Apa artinya ini untuk berbagai audiens

Untuk tim operasi dan pertumbuhan

Anda mendapatkan alur verifikasi massal yang lebih lancar dengan gesekan UI yang lebih sedikit, visibilitas yang lebih baik saat pekerjaan sedang berjalan, dan akses yang lebih jelas ke pekerjaan yang baru saja Anda luncurkan.

Untuk tim produk dan frontend

Anda sekarang memiliki semantik kemajuan yang lebih kuat dan pemisahan yang lebih bersih antara metadata dan status langsung, yang membuat layar dengan beban kemajuan lebih mudah dibangun dan lebih mudah dijelaskan.

Untuk tim backend dan platform

Anda memiliki kontrak status yang lebih kuat untuk verifikasi terdistribusi dan narasi yang lebih bersih tentang apa arti nilai kemajuan yang berbeda.

Untuk pengembang yang mengintegrasikan MCP

Anda sekarang memiliki jawaban yang jauh lebih jelas untuk pertanyaan pengaturan: gunakan MCP jarak jauh plus OAuth untuk klien MCP, dan gunakan kunci API untuk REST API di mana model itu sesuai.

9. Mulai dari Sini

Jika Anda ingin menjelajahi pengalaman yang diperbarui atau jalur integrasi, mulai dari sini:

• Pelajari lebih lanjut tentang produk: Verifikasi email
• Jalankan alur kerja yang lebih besar: Verifikasi email massal
• Pahami dasar-dasarnya: Apa itu verifikasi email?
• Hubungkan MCP dari klien yang didukung: Ringkasan MCP
• Pelajari lebih lanjut tentang pengaturan: Panduan MCP
• Atur Claude Code secara khusus: Panduan Claude Code
• Gunakan integrasi berbasis kunci API sebagai gantinya: Referensi API

Penutup

Rilis ini bukan tentang satu fitur besar yang mencolok. Ini tentang mengetatkan produk di mana ambiguitas telah merayap masuk.

Kami membuat perjalanan verifikasi massal lebih bersih. Kami membuat pemantauan asinkron lebih berguna. Kami membuat pelaporan kemajuan lebih akurat. Dan kami membuat cerita MCP sesuai dengan platform yang sebenarnya kami bangun.

Peningkatan tersebut saling memperkuat satu sama lain.

Produk menjadi lebih mudah dipercaya ketika UI mengatakan lebih sedikit tetapi berarti lebih banyak. Ini menjadi lebih mudah untuk diintegrasikan ketika dokumentasi menjelaskan arsitektur nyata. Dan ini menjadi lebih mudah untuk berkembang ketika antarmuka di bawah pengalaman membawa semantik yang lebih jelas.

Itulah arah yang terus kami dorong di BillionVerify.

Jika Anda sudah menggunakan BillionVerify, perubahan ini seharusnya membuat alur kerja sehari-hari Anda terasa lebih langsung dan lebih dapat diprediksi.

Jika Anda mengevaluasi platform sekarang, pembaruan ini adalah snapshot bagus tentang cara kami berpikir tentang kualitas produk: kejelasan yang dihadap pengguna di atas, kontrak eksplisit di bawah, dan dokumentasi yang sesuai dengan kenyataan.