Sepanjang kitaran pembebasan terkini, kami membuat satu set perubahan yang semuanya menunjuk ke arah yang sama: membuat BillionVerify lebih mudah dipercayai, lebih mudah dipantau, dan lebih mudah diintegrasikan.
Beberapa perubahan tersebut segera kelihatan dalam produk. Pengalaman Bulk Verify lebih bersih selepas penghantaran fail. Halaman sejarah pengesahan lebih berguna sementara pekerjaan masih berjalan. Penunjuk kemajuan kini mencerminkan apa yang pengguna benar-benar peduli daripada mendedahkan mekanik antrian dalaman.
Beberapa perubahan lebih dalam. Kontrak status pengesahan di sebalik UI lebih kaya dan lebih eksplisit. Model data kini membezakan antara kemajuan peringkat emel dan kemajuan pelaksanaan backend, yang memberikan pelanggan asas yang jauh lebih baik untuk memaparkan keadaan realtime yang jujur.
Dan beberapa perubahan menjejaskan pembangun secara langsung. BillionVerify MCP kini telah sepenuhnya beralih daripada persediaan ?api_key= yang lebih lama dan ke dalam model MCP jarak jauh yang dihoskan yang dibina di sekitar OAuth, penemuan sumber terlindung, dan keserasian klien moden. Kami mengemas kini produk, dokumen, halaman pemasaran, dan permukaan pengesahan untuk sepadan dengan realiti itu.
Catatan ini mengumpulkan kemas kini tersebut menjadi satu naratif supaya pelanggan, pembangun, dan pasukan dalaman dapat melihat bagaimana ia sesuai.
Jika anda menginginkan versi ringkas, inilah:
- Pengesahan curah kini mempunyai aliran pasca-muat yang lebih bersih.
- Pemantauan pekerjaan tak segerak lebih informatif dan lebih jujur.
- Antarmuka status backend lebih berstruktur untuk kerja teragih.
- BillionVerify MCP kini mempunyai bentuk jangka panjang yang lebih jelas: titik akhir jarak jauh ditambah OAuth, bukan kunci API yang tertanam dalam URL.
Jika anda menginginkan cerita lengkap, baca teruskan.
Pautan Pantas
- Pengesahan e-mel pukal
- Apakah pengesahan e-mel?
- Gambaran keseluruhan MCP
- Panduan pembangun MCP
- Panduan Claude Code
- Rujukan API
Mengapa pembaruan ini harus bersama-sama
Pada pandangan pertama, rilis ini terlihat seperti beberapa thread terpisah:
- pembersihan frontend pada halaman verifikasi massal
- layar detail riwayat yang lebih kaya
- peningkatan kontrak status backend
- pembersihan autentikasi dan dokumentasi MCP
Namun tema dasar adalah sama di semua: hapus ambiguitas.
Ambiguitas muncul dalam berbagai cara dalam produk perangkat lunak.
Kadang-kadang terlihat seperti UI duplikat setelah pengunggahan file. Pengguna tidak yakin tombol mana yang penting, di mana langkah selanjutnya yang terbaik, atau apakah sistem masih bekerja di latar belakang.
Kadang-kadang terlihat seperti bilah kemajuan yang mengatakan "29% selesai" sementara angka di sekitarnya tidak menjelaskan apa yang diwakili persentase itu. Apakah 29% email diproses? 29% tugas pekerja selesai? 29% hasil digabungkan? Sebagian besar pengguna tidak ingin menguraikan 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-masalah itu.
Kami mengencangkan UX produk seputar apa yang benar-benar perlu diketahui pengguna. Kami mengencangkan antarmuka backend seputar apa yang benar-benar perlu dirender klien. Dan kami mengencangkan cerita MCP yang menghadap pengembang seputar bagaimana platform sebenarnya bekerja hari ini.
I'll translate this English text to Malay (Bahasa Melayu) while keeping all the specified terms unchanged.
1. Bulk Verify kini mempunyai pengalaman pasca-muat naik yang lebih bersih
Bahagian pertama keluaran ini memfokuskan pada momen tepat selepas fail diserahkan.
Momen itu lebih penting daripada yang kelihatan.
Apabila seseorang memuat naik CSV besar untuk pengesahan, mereka belum selesai. Mereka baru sahaja berpindah dari keadaan input ke keadaan pemantauan. Antamuka harus membantu mereka menjawab beberapa soalan segera:
- Adakah fail saya diserahkan dengan berjaya?
- Adakah pemprosesan sudah dimulai?
- Ke mana saya pergi untuk memantau kerja khusus ini?
- Bolehkah saya percaya bahawa sistem akan memberitahu saya apabila ia selesai?
Aliran sebelumnya menjawab soalan-soalan itu, tetapi ia melakukannya dengan terlalu banyak pengulangan. Kad kejayaan, teks status di sekitarnya, dan butang yang tersedia semuanya menarik perhatian ke arah yang sedikit berbeza.
Kami membersihkannya.
Apa yang berubah pada halaman
Keadaan kejayaan penyerahan kini lebih padat dan lebih mudah diimbas. Ikon kejayaan dan tajuk menggunakan lebih sedikit ruang menegak, yang memberikan lebih banyak ruang kepada butiran yang benar-benar peduli oleh pengguna: nama fail, kiraan e-mel, masa pemprosesan yang dianggarkan, dan tindakan seterusnya.
Kemajuan langsung juga ditunjukkan secara lalai selepas penyerahan. Pengguna tidak lagi perlu mengambil langkah tambahan untuk mendedahkan maklumat itu. Jika kerja bergerak, halaman harus menunjukkannya dengan segera.
CTA pasca-penyerahan utama juga telah berubah dengan cara yang penting. Daripada menghantar pengguna ke indeks sejarah umum, tindakan utama kini menghubung terus ke halaman butir kerja yang tepat. Ini mungkin terdengar seperti perubahan kecil, tetapi ia menghapuskan lompatan yang tidak perlu dan menjadikan aliran kerja terasa jauh lebih sengaja.
Kami juga mengeluarkan elemen yang berfungsi dari segi teknikal tetapi tidak bermakna berguna:
- teks status pendua di kawasan muat naik
- butang "Muat Naik Fail Lain" tambahan dalam kad kejayaan
Pengguna masih boleh memuat naik fail lain dari permukaan muat naik utama. Perbezaannya ialah antamuka tidak lagi bersaing dengan dirinya sendiri.
Mengapa ini penting dalam praktik
Pengesahan pukal sering digunakan dalam aliran kerja yang berulang dan operasional. Pengguna mungkin memuat naik berbilang fail setiap hari, memantau beberapa kerja merentas sesi kerja, dan kembali kemudian untuk memuat turun hasil yang ditapis. Dalam persekitaran semacam itu, bahkan potongan UI yang kecil sekalipun terkumpul.
Membersihkan keadaan pasca-muat naik membantu dalam tiga cara:
- Ia mengurangkan jumlah penghuraian skrin yang diperlukan tepat selepas penyerahan.
- Ia menjadikan langkah seterusnya jelas.
- Ia memastikan antamuka sejajar dengan model mental pengguna: "Fail saya masuk. Sekarang saya ingin mengikuti kerja ini."
Ini adalah jenis peningkatan yang jarang membuat tangkapan layar yang meriah itu sendiri, tetapi ia menjadikan produk terasa lebih tenang dan lebih koheren setiap hari.
Contoh: laluan pasca-penyerahan baru
Berikut adalah perjalanan pengguna yang dimaksudkan sekarang:
- Muat naik CSV dalam aliran pengesahan pukal.
- Lihat keadaan kejayaan segera dengan nama fail, kiraan baris, dan ETA.
- Lihat kemajuan langsung tanpa perlu mendedahkannya secara manual.
- Klik satu butang utama untuk membuka halaman butir sejarah tepat untuk kerja itu.
- Kembali kemudian melalui e-mel atau sejarah untuk menyemak hasil dan eksport.
Itu adalah laluan yang lebih mudah daripada:
- Muat naik fail.
- Analisis kawasan status pendua.
- Klik ke sejarah umum.
- Cari baris yang betul.
- Buka semula kerja sasaran.
Pengurangan dalam usaha adalah kecil dalam satu sesi dan ketara sepanjang penggunaan berulang.
2. Sejarah verifikasi kini berkelakuan seperti permukaan pemantauan sebenar
Penambahbaikan besar kedua adalah pada halaman sejarah verifikasi async.
Halaman ini dulu berfungsi, tetapi tipis. Ia boleh menunjukkan bahawa tugas wujud dan sedang dalam kemajuan, tetapi ia belum terasa seperti permukaan yang dirancang untuk pemantauan aktif.
Itu adalah ketidakpadanan untuk tugas verifikasi yang berjalan lama.
Apabila pelanggan membuka halaman perincian sejarah semasa fail masih sedang diproses, mereka tidak hanya mencari nombor peratusan. Mereka cuba memahami:
- fail mana yang dirujuk oleh tugas ini
- berapa besar beban kerja
- berapa banyak kerja yang sudah selesai
- seperti apa campuran hasil awal
- berapa lama kemungkinan tugas itu akan mengambil masa
Kami mereka semula halaman di sekitar realiti itu.
Metadata stabil kini muncul dahulu
Halaman sejarah yang dikemas kini kini bermula dengan kad ringkasan stabil. Kad itu mengumpulkan metadata tugas yang paling penting:
- nama fail asal
- jumlah baris
- bilangan email unik
- anggaran masa pemprosesan
- masa mula
Maklumat ini tidak bergantung pada gelung pengundian realtime. Itu penting kerana konteks stabil harus muncul secepat mungkin, walaupun jika muatan status dinamik masih menetap atau dikemas kini.
Apabila pengguna tiba di halaman, mereka boleh berorientasi segera dan bukannya menunggu respons status langsung untuk melakukan semua kerja.
Kawasan kemajuan langsung jauh lebih kaya
Di bawah ringkasan, pengalaman keadaan berjalan kini jauh lebih baik.
Daripada bar kemajuan kosong dengan konteks terbatas, halaman kini menyurface:
- jumlah yang diproses
- jumlah yang tinggal
- taburan hasil merentas status
- semantik bahasa dan ETA yang sepadan dengan aliran verifikasi pukal utama
Sama pentingnya, ia menghilangkan metrik dalaman yang harus kekal dalaman. Kami sengaja berhenti mendedahkan kiraan tugas pekerja dan ketulan dalam permukaan yang berpandangan pengguna. Nilai-nilai itu boleh berguna dari segi operasional, tetapi ia bukan apa yang pelanggan cuba ukur apabila mereka bertanya, "Sejauh mana tugas saya?"
Soalan yang tepat hampir selalu berpusat email, bukan berpusat antrian.
Alat keadaan selesai kekal utuh
Salah satu kekangan reka bentuk untuk kerja ini ialah kami tidak mahu kehilangan kedalaman analitik halaman tugas selesai.
Jadi kami mengekalkan carta pecahan hasil yang sedia ada dan alat eksport. Pengemaskinian bukan tentang menggantikan pengalaman keadaan selesai. Ia adalah tentang menguatkan bahagian atas halaman dan menjadikan pengalaman keadaan berjalan layak untuk aliran kerja.
Ini bermakna halaman kini melakukan kedua-dua tugas lebih baik:
- semasa pemprosesan, ia berfungsi sebagai permukaan pemantauan
- selepas selesai, ia masih berfungsi sebagai permukaan analisis dan eksport
Contoh: apa yang kini boleh difahami pengguna sekilas
Halaman tugas berjalan kini menjawab semua ini dengan cepat:
- "Ini adalah fail 19,293 baris yang saya muat naik lebih awal."
- "Terdapat 19,010 email unik di dalamnya."
- "Sistem menganggarkan sekitar 33 minit."
- "499 email sudah diverifikasi."
- "Kebanyakan set yang telah selesai setakat ini sah, dengan bahagian tidak sah dan tidak diketahui yang lebih kecil."
Itu adalah model mental yang jauh lebih berguna daripada nombor peratusan tunggal dengan semantik yang tidak jelas.
3. Semantik kemajuan kini lebih jujur
Salah satu pelajaran terbesar dalam produk async ialah bahawa "kemajuan" bukanlah konsep tunggal.
Dalam sistem terdistribusi, terdapat beberapa perkara yang boleh bergerak secara bebas:
- tugas pekerja boleh selesai
- bahagian boleh bergabung
- hasil peringkat email boleh terkumpul
- fail terakhir boleh menjadi boleh dimuat turun
Jika klien hanya menerima satu medan progress generik, ia harus meneka makna mana yang dibawa oleh nombor tersebut. Itulah cara anda berakhir dengan keadaan UI yang secara teknikalnya konsisten tetapi pengalaman yang membingungkan.
Kami ingin memperbaiki perkara itu di tahap kontrak.
Anjakan teras
Antara muka yang dikemaskini memungkinkan pembezaan antara:
email_progresschunk_progressprogress_source
Pembezaan itu memberikan klien asas yang jauh lebih kuat untuk merender kemajuan dengan cara yang sesuai dengan niat pengguna.
Sebagai contoh:
- bar kemajuan yang menghadap pengguna yang besar kini boleh mengutamakan
email_progress - paparan operasi atau diagnostik masih boleh menggunakan
chunk_progress - jika fallback diperlukan,
progress_sourceboleh menjadikan perkara itu jelas
Ini adalah model yang jauh lebih sihat daripada berpura-pura semua peratusan kemajuan bermaksud perkara yang sama.
Muatan contoh
Berikut adalah jenis 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"
}
Tanpa mengetahui apa pun tentang sistem antrian yang mendasari, klien boleh membuat keputusan yang baik daripada respons ini.
Perkara ini penting kerana API tidak hanya mengembalikan data. Mereka menentukan makna.
Mengapa ini lebih baik untuk pelanggan
Pelanggan tidak peduli sama ada pekerja menyelesaikan 7 daripada 96 tugas dalaman jika hanya 499 daripada 19,010 email yang benar-benar telah diproses. Mendedahkan abstraksi kemajuan yang salah mewujudkan kekeliruan, bukan jaminan.
Dengan mengalihkan UI utama ke arah email_progress, produk kini mencerminkan unit kerja yang pengguna peduli.
Mengapa ini lebih baik untuk pasukan frontend
UI tidak perlu lagi membuat kesimpulan terlalu banyak daripada medan peratus tunggal yang samar-samar.
Ini mengurangkan seluruh kelas pepijat produk:
- bar kemajuan yang kelihatan terlalu jauh ke hadapan
- blok ringkasan yang tertinggal di belakang peratusan utama
- salinan status yang janggal yang cuba menjelaskan detail pelaksanaan backend kepada pengguna akhir
Ia juga memberikan pasukan frontend cara yang lebih bersih untuk memisahkan metadata kerja yang stabil daripada data pelaksanaan yang berubah, yang membawa terus ke bahagian berikutnya dalam keluaran.
4. Kontrak status backend kini lebih terstruktur untuk kerja terdistribusi
Perubahan frontend tidak akan bertahan dengan baik tanpa peningkatan kontrak backend.
Kami membuat dua keputusan struktural penting di sini.
Pertama, kami memisahkan metadata stabil dari status langsung
Beberapa field hampir tidak berubah, atau sama sekali tidak berubah, setelah pekerjaan dibuat:
- nama file
- waktu pembuatan
- total baris
- jumlah email unik
- perkiraan waktu pemrosesan
Field lainnya bersifat dinamis:
- status saat ini
- jumlah email yang diproses
- kombinasi hasil langsung
- persentase kemajuan
Mencoba memaksa kedua kelas data melalui jalur polling yang sama adalah sumber umum 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 pekerjaan stabil diperlakukan sebagai metadata
- status pekerjaan langsung diperlakukan sebagai status
Itu terdengar jelas ketika ditulis dengan polos, tetapi memiliki efek bermakna dalam kualitas implementasi.
Halaman detail riwayat kini dapat merender informasi ringkasan stabil dengan cepat, polling hanya apa yang perlu berubah, dan menjaga UI tetap tenang saat pekerjaan berjalan.
Kedua, kami memperluas payload status itu sendiri
Antarmuka status realtime kini lebih cocok untuk pemrosesan asinkron terdistribusi karena membawa gambaran yang lebih kaya tentang apa yang telah terjadi sejauh ini.
Itu mencakup penghitung seperti:
- diproses
- valid
- tidak valid
- tidak diketahui
- berisiko
- catch-all
- peran
- dapat dibuang
- kredit digunakan
Nilai-nilai tersebut membuat antarmuka lebih berguna tidak hanya untuk permukaan kemajuan yang menghadap manusia tetapi juga untuk otomasi dan alur kerja hilir. Klien yang memahami kombinasi hasil saat ini dapat membuat keputusan yang lebih baik tentang peringatan, notifikasi, ekspor, dan pemrosesan pasca.
Contoh: mengapa ini penting di luar UI
Bayangkan aplikasi yang menghadap pelanggan yang dibangun di atas BillionVerify yang ingin:
- menampilkan distribusi kualitas langsung saat daftar berjalan
- memberitahu pengguna jika pekerjaan menghasilkan tingkat tidak valid yang tidak biasa
- menawarkan ekspor yang disaring segera setelah set hasil yang berguna ada
- memberdayakan dashboard dukungan atau ops tanpa memerlukan rekayasa untuk memeriksa status pekerja 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 yang terlihat pertama adalah "batang kemajuan terlihat lebih baik." Batang kemajuan yang lebih baik sering kali adalah gejala kontrak yang lebih baik.
5. MCP kini telah sepenuhnya berpindah ke era OAuth jarak jauh
Bahagian besar terakhir pembaruan ini adalah menghadap pengembang, tetapi ia adalah salah satu koreksi produk jangka panjang yang paling penting dalam rilis ini.
BillionVerify MCP kini dipersembahkan dan didokumentasikan dalam bentuk yang seharusnya untuk klien jarak jauh modern:
- titik akhir jarak jauh yang dihosting
- otorisasi berbasis OAuth
- penemuan sumber daya yang dilindungi
- akses token Bearer standar
Titik akhirnya adalah:
https://mcp.billionverify.com/mcp
Ini penting karena pola pengaturan yang lebih tua dapat bertahan dalam materi publik jauh setelah platform telah bergerak maju secara internal. Dalam kasus kami, beberapa dokumen dan permukaan pemasaran masih menyiratkan bahwa MCP dapat terhubung melalui kunci API tertanam URL dan pembungkus curl --stdio.
Itu bukan lagi bentuk yang tepat untuk BillionVerify MCP.
Model mental yang lama
Pola yang lebih tua terlihat kurang lebih seperti ini:
curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"
Model tersebut menggabungkan beberapa masalah menjadi satu langkah pengaturan yang canggung:
- transportasi
- autentikasi
- penanganan rahasia
- perilaku pembungkus lokal
Ia juga mengirimkan sinyal yang salah tentang bagaimana pelanggan modern harus menggunakan server MCP jarak jauh yang dihosting.
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 yang kompatibel lainnya, titik awal yang tepat hanyalah titik akhir itu sendiri:
https://mcp.billionverify.com/mcp
Klien menemukan metadata sumber daya yang dilindungi, mengikuti alur otorisasi, dan kemudian menggunakan token akses Bearer untuk panggilan autentik.
Perbedaan paling penting: autentikasi MCP bukan autentikasi REST
Salah satu alasan dokumen yang lebih tua memerlukan pembersihan adalah kunci API masih penting di BillionVerify. Tetapi mereka tidak lagi termasuk dalam cerita bootstrap MCP.
Pembagian yang bersih adalah:
- REST API menggunakan kunci API
- MCP jarak jauh menggunakan OAuth
Perbedaan itu 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 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 awam dan pemasaran kini sepadan dengan produk
Peningkatan seni bina hanya menyelesaikan sebahagian daripada masalah jika bahan awam masih menceritakan kisah yang berbeza.
Itulah sebabnya kami menganggap pembersihan dokumentasi dan pemasaran MCP sebagai sebahagian daripada keluaran yang sama.
Kami mengemas kini:
- halaman MCP awam
- panduan MCP
- panduan Claude Code
- titik masuk panduan AI
- varian dokumentasi multibahasa
- salinan FAQ pemasaran setempat
Matlamatnya mudah: harus ada satu jawapan yang jelas kepada soalan, "Bagaimana cara saya menyambungkan BillionVerify MCP?"
Kini ada.
Mengapa ini penting untuk pembangun
Apabila dokumentasi awam ketinggalan realiti pelaksanaan, pembangun membayar harganya dalam tiga cara:
- Percubaan persediaan yang gagal
- Keyakinan yang hilang terhadap platform
- Beban sokongan tambahan untuk menjelaskan apa yang sepatutnya jelas
Dengan menyelaraskan permukaan awam dengan model OAuth jauh sebenar, kami mengurangkan geseran yang tidak perlu sebelum ia menjadi masalah sokongan.
Mengapa ini penting untuk kedudukan platform
Ekosistem MCP bergerak dengan cepat. Apabila lebih banyak pasukan menilai alatan melalui ChatGPT, Claude Code, dan klien AI lain, kualiti pengalaman integrasi pertama lebih penting.
Produk yang kelihatan moden pada lapisan protokol tetapi ketinggalan zaman dalam panduan persediaan awamnya mewujudkan keraguan tepat di tempat ia sepatutnya membangun kepercayaan.
Itulah sebabnya kami juga memperkuat permukaan daftar masuk dan persetujuan dengan Terma yang lebih jelas, Privasi, dan keterlihatan hubungan sokongan. Penyemak, pembangun, dan penilai perusahaan semuanya mendapat manfaat apabila isyarat kepercayaan adalah eksplisit.
7. Pandangan praktis sebelum dan sesudah keluaran ini
Satu cara berguna untuk memahami keluaran adalah dengan membandingkan pengalaman pengguna dan pembangun sebelum dan sesudah.
Sebelum
- Fail verifikasi pukal boleh diserahkan dengan berjaya, tetapi keadaan pasca-hantar masih mempunyai antara muka pendua dan langkah seterusnya yang kurang jelas.
- Halaman perincian sejarah menunjukkan aktiviti, tetapi ia belum terasa seperti permukaan pemantauan penuh.
- Nilai peratusan-lengkap boleh wujud tanpa memberitahu pengguna dengan jelas sama ada ia mewakili e-mel yang diproses atau penyiapan tugas dalaman.
- Bahan awam MCP masih sebahagiannya mencerminkan cerita persediaan warisan
?api_key=.
Sesudah
- Pengalaman pasca-hantar lebih bersih, lebih padat, dan lebih langsung.
- Kemajuan langsung muncul secara lalai dalam aliran pukal.
- CTA utama selepas penghantaran membawa pengguna terus ke halaman perincian kerja yang tepat.
- Halaman perincian sejarah menunjukkan metadata ringkasan stabil ditambah keterlihatan hasil langsung yang lebih kaya.
- Kemajuan yang menghadap pengguna kini berpusat pada semantik kemajuan peringkat e-mel.
- Kiraan tugas dalaman tidak lagi terdedah sebagai metrik yang menghadap pelanggan.
- Antara muka status bahagian belakang lebih baik berstruktur untuk pelanggan masa nyata dan kerja yang diedarkan.
- Bahan awam MCP kini secara konsisten mencerminkan seni bina OAuth jauh.
Ia bukan satu ciri. Ia adalah lintasan kualiti yang bermakna merentas aliran kerja.
8. Apakah ini bermakna untuk audiens yang berbeza
Untuk pasukan operasi dan pertumbuhan
Anda mendapatkan aliran kerja pengesahan pukal yang lebih lancar dengan geseran UI yang lebih sedikit, keterlihatan yang lebih baik semasa pekerjaan berjalan, dan akses yang lebih jelas kepada pekerjaan tepat yang baru anda lancarkan.
Untuk pasukan produk dan frontend
Anda kini mempunyai semantik kemajuan yang lebih kuat dan pemisahan yang lebih bersih antara metadata dan status langsung, yang menjadikan skrin beban kemajuan lebih mudah dibina dan lebih mudah dijelaskan.
Untuk pasukan backend dan platform
Anda mempunyai kontrak status yang lebih kuat untuk pengesahan teragih dan cerita yang lebih bersih tentang apa yang sebenarnya bermakna nilai kemajuan yang berbeza.
Untuk pembangun yang menyepadukan MCP
Anda kini mempunyai jawapan yang jauh lebih jelas kepada soalan persediaan: gunakan MCP jauh ditambah OAuth untuk klien MCP, dan gunakan kunci API untuk REST API di mana model itu sesuai.
9. Tempat untuk Bermula
Jika anda ingin meneroka pengalaman yang dikemas kini atau laluan integrasi, mulakan di sini:
- Ketahui lebih lanjut tentang produk: Email verification
- Jalankan alur kerja yang lebih besar: Bulk email verification
- Fahami asas-asasnya: What is email verification?
- Sambungkan MCP daripada klien yang disokong: MCP overview
- Pelajari lebih mendalam tentang persediaan: MCP guide
- Sediakan Claude Code khususnya: Claude Code guide
- Gunakan integrasi berasaskan kunci API: API reference
Penutupan
Keluaran ini bukan tentang satu permukaan yang besar dan mencolok. Ini tentang mengetatkan produk di mana kekaburan telah merayap masuk.
Kami membuat perjalanan verifikasi massal lebih bersih. Kami membuat pemantauan asinkron lebih berguna. Kami membuat pelaporan kemajuan lebih jujur. 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. Menjadi lebih mudah untuk diintegrasikan ketika dokumen menggambarkan arsitektur yang sebenarnya. Dan menjadi lebih mudah untuk berkembang ketika antarmuka di bawah pengalaman membawa semantik yang lebih jelas.
Itulah arah yang terus kami dorong untuk BillionVerify.
Jika Anda sudah menggunakan BillionVerify, perubahan ini harus membuat alur kerja sehari-hari Anda terasa lebih langsung dan lebih dapat diprediksi.
Jika Anda mengevaluasi platform sekarang, pembaruan ini adalah gambaran yang baik tentang cara kami berpikir tentang kualitas produk: kejelasan yang menghadap pengguna di atas, kontrak eksplisit di bawah, dan dokumentasi yang sesuai dengan kenyataan.