Over de laatste release-cyclus hebben we een reeks wijzigingen aangebracht die allemaal in dezelfde richting wijzen: BillionVerify gemakkelijker te vertrouwen, gemakkelijker te monitoren en gemakkelijker te integreren maken.
Sommige van deze wijzigingen zijn onmiddellijk zichtbaar in het product. De Bulk Verify ervaring is schoner na bestandsverzending. De verificatiegeschiedenispagina is nuttiger terwijl een taak nog steeds wordt uitgevoerd. Voortgangsindicatoren weerspiegelen nu wat gebruikers echt belangrijk vinden in plaats van interne wachtrijmechanismen bloot te leggen.
Sommige wijzigingen gaan dieper. Het verificatiestatuscontract achter de UI is rijker en explicieter. Het gegevensmodel maakt nu onderscheid tussen voortgang op e-mailniveau en voortgang van backend-uitvoering, wat clients een veel beter fundament geeft voor het weergeven van eerlijke realtime-status.
En sommige wijzigingen hebben directe gevolgen voor ontwikkelaars. BillionVerify MCP is nu volledig afgestapt van de oudere ?api_key= setupvorm en naar een gehosted extern MCP-model gebouwd rond OAuth, beschermde-resourcedetectie en moderne clientcompatibiliteit. We hebben het product, de documentatie, de marketingpagina's en de auth-oppervlakken bijgewerkt om die realiteit te weerspiegelen.
Dit artikel brengt die updates samen in één verhaal zodat klanten, ontwikkelaars en interne teams kunnen zien hoe ze passen.
Als je de korte versie wilt, hier is het:
Bulkverificatie heeft nu een schonere stroom na uploaden.
Async-taakbewaking is meer informatief en eerlijker.
De backend-statusinterface is beter gestructureerd voor gedistribueerd werk.
BillionVerify MCP heeft nu een duidelijkere lange-termijnvorm: extern eindpunt plus OAuth, niet URL-ingebedde API-sleutels.
Als je het volledige verhaal wilt, lees dan verder.
Begin vandaag nog met het verifiëren van e-mails met BillionVerify. Ontvang 100 gratis credits bij aanmelding - geen creditcard vereist. Sluit u aan bij duizenden bedrijven die hun e-mailmarketing-ROI verbeteren met nauwkeurige e-mailverificatie.
Geen creditcard vereist · 100+ gratis credits per dag · Start binnen 30 seconden
99.9%
Nauwkeurigheid
Real-time
API-snelheid
$0.00014
Per e-mail
100/day
Altijd gratis
Ambiguïteit manifesteert zich op verschillende manieren in softwareproducten.
Soms ziet het eruit als dubbele UI na een bestandsupload. Gebruikers zijn niet zeker welke knop belangrijk is, waar de beste volgende stap is, of het systeem nog steeds op de achtergrond werkt.
Soms ziet het eruit als een voortgangsbalk die "29% compleet" zegt terwijl de omringende nummers niet uitleggen wat dat percentage vertegenwoordigt. Is het 29% van e-mails verwerkt? 29% van worker taken voltooid? 29% van resultaten samengevoegd? De meeste gebruikers willen geen queue architectuur decoderen alleen maar om een taak te controleren.
Soms zit ambiguïteit in developer onboarding. Een product kan al één architectuur in productie ondersteunen terwijl delen van de openbare documentatie nog steeds een ouder verbindingsmodel suggereren. Dat creëert setup fouten, verwarring en onnodig wantrouwen.
Deze release is ons antwoord op die problemen.
We hebben de product UX aangescherpt rond wat gebruikers eigenlijk moeten weten. We hebben de backend interfaces aangescherpt rond wat clients eigenlijk moeten renderen. En we hebben het developer-facing MCP verhaal aangescherpt rond hoe het platform vandaag daadwerkelijk werkt.
1. Bulk Verify heeft nu een schonere ervaring na het uploaden
Het eerste deel van deze release concentreerde zich op het moment direct na het indienen van een bestand.
Dat moment is belangrijker dan het lijkt.
Wanneer iemand een groot CSV-bestand voor verificatie uploadt, zijn ze niet klaar. Ze zijn zojuist van een invoertoestand naar een monitoringstoestand gegaan. De interface moet hen helpen een paar directe vragen te beantwoorden:
Is mijn bestand succesvol ingediend?
Is de verwerking al aan de gang?
Waar kan ik deze specifieke taak monitoren?
Kan ik erop vertrouwen dat het systeem mij waarschuwt wanneer het klaar is?
De vorige flow beantwoordde deze vragen, maar deed dat met teveel herhaling. De succeskaart, de omringende statustekst en de beschikbare knoppen trokken allemaal iets anders de aandacht.
We hebben dat opgeruimd.
Wat is er op de pagina veranderd
De successtatus na indiening is nu compacter en gemakkelijker te scannen. Het succespicto en de titel nemen minder verticale ruimte in beslag, wat meer ruimte geeft aan de details waar gebruikers om geven: bestandsnaam, e-mailaantallen, geschatte verwerkingstijd en de volgende actie.
Directe voortgang wordt ook standaard weergegeven na indiening. Gebruikers hoeven geen extra stap te nemen om die informatie zichtbaar te maken. Als een taak in voortgang is, moet de pagina dat onmiddellijk weergeven.
De belangrijkste CTA na indiening is ook op een belangrijke manier veranderd. In plaats van gebruikers naar de generieke geschiedenisindesx te sturen, linkt de primaire actie nu rechtstreeks naar de exacte taakdetailpagina. Dat klinkt als een kleine verandering, maar het elimineert een onnodig stap en maakt de workflow veel doelbewuster voelen.
We hebben ook elementen verwijderd die technisch functioneel waren maar niet zinvol nuttig:
dubbele statustekst in het uploadgedeelte
een extra knop "Upload ander bestand" in de succeskaart
Gebruikers kunnen nog steeds een ander bestand uploaden via het hoofduploadoppervlak. Het verschil is dat de interface niet meer tegen zichzelf concurreert.
Waarom dit in de praktijk belangrijk is
Bulkverificatie wordt vaak gebruikt in repetitieve, operationele workflows. Gebruikers kunnen meerdere bestanden per dag uploaden, verschillende taken over een werksessie monitoren en later terugkomen om gefilterde resultaten te downloaden. In dat soort omgeving voegen zelfs kleine stukjes UI-dubbeling op.
Het opschonen van de status na het uploaden helpt op drie manieren:
Het vermindert de hoeveelheid schermanalyse die direct na indiening nodig is.
Het maakt de volgende stap duidelijk.
Het houdt de UI afgestemd op het mentale model van de gebruiker: "Mijn bestand is erin. Nu wil ik deze taak volgen."
Dit is het soort verbetering dat zelden op zichzelf een opvallende schermafbeelding oplevert, maar het doet het product elke dag kalmer en coherenter aanvoelen.
Voorbeeld: het nieuwe pad na indiening
Dit is nu de beoogde gebruikersreis:
Upload een CSV in de bulkverificatiestroom.
Zie onmiddellijk een successtatus met bestandsnaam, rijaantal en ETA.
Zie directe voortgang zonder deze handmatig zichtbaar te hoeven maken.
Klik op één primaire knop om de exacte geschiedenisinformatiepagina voor die taak te openen.
Keer later via e-mail of geschiedenisinformatie terug om resultaten en exports te bekijken.
Dat is een eenvoudiger pad dan:
Bestand uploaden.
Dubbele statusgebieden parseren.
Klik in generieke geschiedenisinformatie.
Zoek de juiste rij.
Open de doeltaak opnieuw.
De reductie in inspanning is klein in een enkele sessie en aanzienlijk over herhaald gebruik.
2. Verificatiegeschiedenis gedraagt zich nu als een echt monitoringoppervlak
De tweede grote verbetering betrof de asynchrone verificatiegeschiedenis-pagina.
Deze pagina was functioneel, maar minimaal. Het kon laten zien dat een job bestond en dat deze in uitvoering was, maar het voelde nog niet als een oppervlak dat ontworpen was voor actieve monitoring.
Dat is een mismatch voor een langlopende verificatiejob.
Wanneer een klant een historiedetailpagina opent terwijl een bestand nog steeds wordt verwerkt, zoeken zij niet alleen naar een percentagenummer. Zij proberen te begrijpen:
naar welk bestand deze job verwijst
hoe groot de werkbelasting is
hoeveel werk al is voltooid
hoe de vroege resultaatmix eruit ziet
hoe lang de job waarschijnlijk duurt
We hebben de pagina rond die werkelijkheid herontworpen.
Stabiele metagegevens verschijnen nu eerst
De bijgewerkte geschiedenis-pagina begint nu met een stabiele samenvattingskaart. Die kaart brengt de belangrijkste jobmetagegevens samen:
originele bestandsnaam
totaal aantal rijen
aantal unieke e-mails
geschatte verwerkingstijd
starttijd
Deze informatie hangt niet af van de realtime polling-loop. Dat is belangrijk omdat stabiele context zo snel mogelijk moet verschijnen, zelfs als de dynamische statuspayload nog steeds aan het bijdragen of bijwerken is.
Wanneer gebruikers op de pagina terechtkomen, kunnen zij zich onmiddellijk oriënteren in plaats van te wachten tot een live statusrespons al het werk doet.
Het live-voortgangsgebied is veel rijker
Onder de samenvatting is de live-statuservaring nu aanzienlijk beter.
In plaats van een eenvoudige voortgangsbalk met beperkte context, toont de pagina nu:
verwerkt volume
resterend volume
resultaatdistributie over statussen
taal- en ETA-semantiek die overeenkomt met de hoofdverificatiestroom
Net zo belangrijk is dat het interne metrische gegevens verwijdert die intern moeten blijven. We hebben opzettelijk gestopt met het vrijgeven van worker-task- en chunk-tellingen in het gebruikersoppervlak. Die waarden kunnen operationeel nuttig zijn, maar ze zijn niet wat klanten willen meten wanneer zij vragen: "Hoe ver ben ik met mijn job?"
De juiste vraag is bijna altijd e-mailcentrisch, niet wachtrijcentrisch.
Voltooide-state-tools blijven intact
Een van de ontwerpbeperkingen voor dit werk was dat we de analytische diepte van de voltooide jobpagina niet wilden verliezen.
We hebben dus de bestaande resultaatverdelingsgraaf en exporttools behouden. De update ging niet over het vervangen van de voltooide-state-ervaring. Het ging over het versterken van de bovenkant van de pagina en het waardig maken van de live-state-ervaring voor de workflow.
Dit betekent dat de pagina nu beide taken beter uitvoert:
tijdens verwerking werkt het als een monitoringoppervlak
na voltooiing werkt het nog steeds als een analyse- en exportoppervlak
Voorbeeld: wat gebruikers nu in één oogopslag kunnen begrijpen
Een live jobpagina beantwoordt nu snel al deze vragen:
"Dit is het bestand met 19.293 rijen dat ik eerder heb geüpload."
"Er zijn 19.010 unieke e-mails in."
"Het systeem schat ongeveer 33 minuten in."
"499 e-mails zijn al geverifieerd."
"Het merendeel van de voltooide set tot nu toe is geldig, met een kleiner aandeel ongeldig en onbekend."
Dat is een veel bruikbaarder mentaal model dan een enkel percentagenummer met onduidelijke semantiek.
3. De voortgangssemantiek is nu eerlijker
Een van de belangrijkste lessen in async-producten is dat "voortgang" niet één enkel concept is.
In een gedistribueerd systeem zijn er verschillende dingen die onafhankelijk van elkaar kunnen veranderen:
worker-taken kunnen worden voltooid
chunks kunnen samenvoegen
resultaten op e-mailniveau kunnen zich ophopen
eindbestanden kunnen downloadbaar worden
Als een client slechts één generiek progress-veld ontvangt, moet het gissen welke betekenis het getal heeft. Op die manier krijg je UI-states die technisch consistent zijn maar gebruiksmogelijkheden verwarrend.
We wilden dit op contractniveau oplossen.
De kernverandering
De bijgewerkte interface maakt het mogelijk onderscheid te maken tussen:
email_progress
chunk_progress
progress_source
Dit onderscheid geeft clients een veel sterkere basis om voortgang op een manier weer te geven die aansluit bij de gebruikersintentie.
Bijvoorbeeld:
de grote voortgangsbalk gericht op gebruikers kan nu email_progress voorrang geven
operationele of diagnostische weergaven kunnen nog steeds chunk_progress gebruiken
als een fallback nodig is, kan progress_source dit expliciet maken
Dit is een veel gezonder model dan doen alsof alle voortgangspercentages hetzelfde betekenen.
Voorbeeld-payload
Hier ziet u het soort vorm dat dit mogelijk maakt:
Zonder iets te weten over het onderliggende wachtrijsysteem, kan een client goede beslissingen nemen op basis van dit antwoord.
Dat is belangrijk omdat API's niet zomaar gegevens retourneren. Ze definiëren betekenis.
Waarom dit beter is voor klanten
Klanten geven niet om of een worker 7 van de 96 interne taken heeft voltooid als slechts 499 van de 19.010 e-mails daadwerkelijk zijn verwerkt. Het blootstellen van de verkeerde voortgangsabstractie veroorzaakt verwarring, niet geruststelling.
Door de primaire UI naar email_progress te verplaatsen, weerspiegelt het product nu de werkeenheid waar gebruikers werkelijk om geven.
Waarom dit beter is voor frontend-teams
De UI hoeft niet langer te veel af te leiden uit één enkel dubbelzinnig percentageveld.
Dit vermindert een hele klasse van productbugs:
voortgangsstaven die te ver vooruit lijken
samenvattingsblokken die achter het hoofdpercentage achterlopen
ongemakkelijke statuskopiëren die backend-implementatiedetails aan eindgebruikers proberen uit te leggen
Het geeft frontend-teams ook een schonere manier om stabiele jobmetagegevens te scheiden van veranderende uitvoeringsgegevens, wat direct leidt tot het volgende deel van de release.
4. De backend-statuscontract is nu beter gestructureerd voor gedistribueerd werk
De frontendwijzigingen zouden zonder verbeteringen in de backendcontract niet goed samenwerken.
We hebben hier twee belangrijke structurele beslissingen genomen.
Ten eerste hebben we stabiele metagegevens gescheiden van live-status
Sommige velden veranderen nauwelijks of helemaal niet nadat een taak is gemaakt:
bestandsnaam
aanmaaktijd
totaal rijen
aantal unieke e-mailadressen
geschatte verwerkingstijd
Andere velden zijn inherent dynamisch:
huidige status
verwerkt aantal e-mailadressen
live-resultaatsamenstelling
voortgangspercentages
Het forceren van beide klassen gegevens via hetzelfde pollingpad is een veelvoorkomende bron van UI-ongemak. De frontend eindigt ermee te wachten op gegevens die onmiddellijk beschikbaar hadden moeten zijn, terwijl ook stabiele gegevens vaker worden opnieuw aangevraagd dan nodig is.
Het nieuwe model is schoner:
stabiele taakmetagegevens worden als metagegevens behandeld
live-taakstatus wordt als status behandeld
Dat klinkt voor de hand liggend wanneer duidelijk opgeschreven, maar het heeft betekenisvolle effecten op implementatiekwaliteit.
De pagina met geschiedenisinformatie kan nu stabiele samenvattingsinformatie snel weergeven, alleen het benodigde bevragen, en de UI rustig houden terwijl de taak wordt uitgevoerd.
Ten tweede hebben we de statuspayload zelf uitgebreid
De realtime-statusinterface is nu beter geschikt voor gedistribueerd asynchrone verwerking omdat deze een rijker beeld draagt van wat tot nu toe is gebeurd.
Dit omvat tellers zoals:
verwerkt
geldig
ongeldig
onbekend
riskant
catch-all
rol
wegwerpbaar
gebruikte tegoedenals
Deze waarden maken de interface niet alleen nuttiger voor op mensen gerichte voortgangsoppervlakken, maar ook voor automatisering en downstreamworkflows. Een client die de huidige resultaatsamenstelling begrijpt, kan betere beslissingen nemen over waarschuwingen, meldingen, exporten en nabewerking.
Voorbeeld: waarom dit meer betekent dan alleen de UI
Stel je een app voor eindgebruikers voor op BillionVerify die wil:
live kwaliteitsverdeling weergeven terwijl een lijst wordt uitgevoerd
een gebruiker waarschuwen als een taak een ongewoon hoog ongeldig percentage produceert
gefilterde exporten aanbieden zodra nuttige resultatensets beschikbaar zijn
een ondersteunings- of operationsdashboard aansturen zonder dat technisch personeel ruwe werkerstatus hoeft in te specteren
Al die gebruiksscenario's worden gemakkelijker wanneer de backend-statuscontract expliciet en rijker genoeg is.
Dit is waarom backend-interfacework belangrijk is, zelfs wanneer de eerste zichtbare verandering "de voortgangsbalk ziet er beter uit" is. Een betere voortgangsbalk is vaak het symptoom van een beter contract.
5. MCP is nu volledig naar de remote OAuth-era overgegaan
Het laatste grote onderdeel van deze update is gericht op ontwikkelaars, maar het is een van de belangrijkste langetermijnproductcorrecties in deze release.
BillionVerify MCP wordt nu gepresenteerd en gedocumenteerd in de vorm die het zou moeten hebben voor moderne remote clients:
een gehoste remote endpoint
OAuth-gebaseerde autorisatie
protected-resource discovery
standaard Bearer token-toegang
De endpoint is:
https://mcp.billionverify.com/mcp
Dit is belangrijk omdat oudere setup-patronen lang in openbare materialen kunnen blijven hangen nadat een platform intern al verder is gegaan. In ons geval suggereerden sommige docs en marketingoppervlakken nog dat MCP kon worden verbonden via URL-ingebedde API-sleutels en curl --stdio wrappers.
Dat is niet langer de juiste vorm voor BillionVerify MCP.
Dit model combineert verschillende aandachtspunten in één onhandig setupstap:
transport
authenticatie
secret handling
lokaal wrapper-gedrag
Het stuurt ook het verkeerde signaal over hoe een gehoste remote MCP-server door moderne clients moet worden gebruikt.
Het nieuwe mentale model
Het huidige model is schoner.
Voor Claude Code is de aanbevolen setup:
claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp
Vervolgens in Claude Code:
/mcp
Vanaf daar voltooit de client de OAuth-flow in de browser.
Voor ChatGPT en andere compatibele remote MCP-clients is het juiste startpunt eenvoudig de endpoint zelf:
https://mcp.billionverify.com/mcp
De client ontdekt de protected-resource metadata, volgt de autorisatiestroom en gebruikt vervolgens Bearer access tokens voor geverifieerde oproepen.
Het belangrijkste onderscheid: MCP-auth is geen REST-auth
Een reden waarom de oudere docs opschoning nodig hadden, is dat API-sleutels nog steeds belangrijk zijn in BillionVerify. Maar ze horen niet meer bij het MCP-bootstrap-verhaal.
De schone scheiding is:
REST API gebruikt API-sleutels
remote MCP gebruikt OAuth
Dit onderscheid is nu veel duidelijker in het hele productlandschap.
Als een ontwikkelaar het volgende gebruikt:
ChatGPT
Claude Code
een ander OAuth-geschikt remote MCP-client
moeten zij het remote MCP-pad gebruiken.
Als zij bouwen aan:
backend-naar-backend automatisering
API-sleutel-aangestuurde scripts
clients die alleen lokale stdio plus API-sleutels ondersteunen
Het doel was eenvoudig: er zou één duidelijk antwoord moeten zijn op de vraag: "Hoe verbind ik BillionVerify MCP?"
Nu is er één.
Waarom dit voor ontwikkelaars belangrijk is
Wanneer openbare docs achter de implementatierealiteit achterlopen, betalen ontwikkelaars op drie manieren de prijs:
Mislukte instellingspogingen
Verloren vertrouwen in het platform
Extra ondersteuningslast om duidelijk te maken wat voor de hand liggend had moeten zijn
Door het openbare oppervlak op één lijn te brengen met het werkelijke externe OAuth-model, verminderen we onnodige wrijving voordat het een ondersteuningsprobleem wordt.
Waarom dit voor platformpositionering belangrijk is
Het MCP-ecosysteem evolueert snel. Naarmate meer teams tools evalueren via ChatGPT, Claude Code en andere AI-clients, is de kwaliteit van de eerste integratieervaring van meer belang.
Een product dat op protocolniveau modern uitziet maar verouderd in de openbare installatiehulp, creëert aarzeling juist waar het vertrouwen zou moeten opbouwen.
Daarom hebben we ook de aanmeldings- en toestemmingsvlakken versterkt met duidelijkere voorwaarden, privacy en zichtbaarheid van ondersteuningscontacten. Reviewers, ontwikkelaars en enterprise-evaluators profiteren allemaal als de vertrouwenssignalen expliciet zijn.
7. Een praktische voor-en-na-weergave van deze release
Een nuttige manier om de release te begrijpen is het vergelijken van de gebruikers- en ontwikkelaarservaring voor en na.
Daarvoor
Een bulkverificatiebestand kon succesvol worden ingediend, maar de status na indiening had nog steeds dubbele UI en minder duidelijke volgende stappen.
De historiedetailpagina toonde activiteit, maar voelde nog niet als een volledig monitoringoppervlak.
Een voltooiingspercentage kon bestaan zonder gebruikers duidelijk te zeggen of het verwerkte e-mails of interne taakvoltooiing vertegenwoordigde.
MCP-publicatiematerialen weerspiegelden nog gedeeltelijk een verouderde ?api_key=-instellingsverhaal.
Daarna
De ervaring na indiening is schoner, compacter en directer.
Live voortgang verschijnt standaard in de bulkstroom.
De belangrijkste CTA na indiening brengt gebruikers rechtstreeks naar de exacte taakdetailpagina.
Historiedetailpagina's tonen stabiele samenvattingsmetagegevens plus rijkere live-resultaatzichtbaarheid.
Gebruikersgerichte voortgang richt zich nu op semantiek van voortgang op e-mailniveau.
Interne taakaantallen worden niet langer als metrische gegevens voor klanten weergegeven.
De interface voor back-endstatus is beter gestructureerd voor realtime-clients en gedistribueerde taken.
MCP-publicatiematerialen weerspiegelen nu consistent de architectuur voor externe OAuth.
Dit is niet één functie. Dit is een betekenisvolle kwaliteitscontrole over een werkstroom.
8. Wat dit betekent voor verschillende doelgroepen
Voor operations- en groeiteams
Je krijgt een soepelere workflow voor bulkverificatie met minder UI-wrijving, beter inzicht terwijl jobs worden uitgevoerd, en duidelijker toegang tot de exacte job die je zojuist hebt gestart.
Voor product- en frontendteams
Je hebt nu sterkere progress-semantiek en schonere scheiding tussen metadata en live-status, wat progress-zware schermen gemakkelijker maakt om te bouwen en uit te leggen.
Voor backend- en platformteams
Je hebt een sterker statuscontract voor gedistribueerde verificatie en een duidelijker verhaal over wat verschillende progresswaarden werkelijk betekenen.
Voor ontwikkelaars die MCP integreren
Je hebt nu een veel duidelijker antwoord op de instellingsvraag: gebruik remote MCP plus OAuth voor MCP-clients, en gebruik API-sleutels voor de REST API waar dat model geschikt is.
9. Waar te beginnen
Als je de vernieuwde ervaring of integratiepadden wilt verkennen, begin hier:
Gebruik in plaats daarvan API-sleutelgebaseerde integratie: API-referentie
Sluiting
Deze release ging niet om één groot opvallend oppervlak. Het ging om het verstevigen van het product waar onduidelijkheid was geslopen.
We hebben de bulk verification journey schoner gemaakt. We hebben async monitoring nuttiger gemaakt. We hebben progress reporting waarheidsgetrouwer gemaakt. En we hebben het MCP-verhaal aangepast aan het platform dat we daadwerkelijk aan het bouwen zijn.
Deze verbeteringen versterken elkaar.
Een product wordt gemakkelijker vertrouwd wanneer de UI minder zegt maar meer betekent. Het wordt gemakkelijker te integreren wanneer de docs de echte architectuur beschrijven. En het wordt gemakkelijker te evolueren wanneer de interfaces onder de ervaring scherpere semantiek dragen.
Dat is de richting waarin we BillionVerify blijven duwen.
Als je BillionVerify al gebruikt, zouden deze wijzigingen je dagelijkse workflow directer en voorspelbaarder moeten voelen.
Als je het platform nu aan het evalueren bent, is deze update een goed moment om te zien hoe we over productkwaliteit denken: gebruikersgericht duidelijkheid bovenin, expliciete contracten eronder, en documentatie die met de werkelijkheid overeenkomt.
