Product Update: Betere Bulk Verification UX, Eerlijkere Async Progress, en een Modern MCP Connection Model

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.

Snelle koppelingen

• Bulkemailverificatie
• Wat is e-mailverificatie?
• MCP-overzicht
• MCP-ontwikkelaarshandleiding
• Claude Code-gids
• API-referentie

Waarom deze updates bij elkaar horen

Op het eerste gezicht ziet deze release eruit als verschillende gescheiden onderwerpen:

• een frontend opruiming op de bulk verificatie pagina
• een uitgebreider geschiedenisdetailscherm
• een backend statuscontract upgrade
• een MCP authenticatie en documentatieopruiming

Maar het onderliggende thema is hetzelfde voor allemaal: ambiguïteit verwijderen.

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 succesp​icto 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:

1. Het vermindert de hoeveelheid schermanalyse die direct na indiening nodig is.
2. Het maakt de volgende stap duidelijk.
3. 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:

1. Upload een CSV in de bulkverificatiestroom.
2. Zie onmiddellijk een successtatus met bestandsnaam, rij​aantal en ETA.
3. Zie directe voortgang zonder deze handmatig zichtbaar te hoeven maken.
4. Klik op één primaire knop om de exacte geschiedenisinformatiepagina voor die taak te openen.
5. Keer later via e-mail of geschiedenisinformatie terug om resultaten en exports te bekijken.

Dat is een eenvoudiger pad dan:

1. Bestand uploaden.
2. Dubbele statusgebieden parseren.
3. Klik in generieke geschiedenisinformatie.
4. Zoek de juiste rij.
5. 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:

{
  "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"
}

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.

Het oude mentale model

Het oudere patroon zag er ruwweg als volgt uit:

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

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

moeten zij de API-referentie en REST-flow gebruiken.

Dit is geen cosmetisch onderscheid. Het is een productgrens, en de documentatie zou dit duidelijk moeten maken.

6. Openbare docs en marketing stemmen nu overeen met het product

Een architectuurupgrade lost maar een deel van het probleem op als de openbare materialen nog steeds een ander verhaal vertellen.

Daarom hebben we de MCP-documentatie en marketing-opschoning als onderdeel van dezelfde release behandeld.

We hebben bijgewerkt:

• de openbare MCP-pagina
• de MCP-gids
• de Claude Code-gids
• insteekpunten van AI-gidsen
• meertalige documentvarianten
• gelokaliseerde marketing FAQ-kopie

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:

1. Mislukte instellingspogingen
2. Verloren vertrouwen in het platform
3. 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:

• Meer informatie over het product: E-mailverificatie
• Grotere werkstromen uitvoeren: Bulk e-mailverificatie
• Begrijp de basisprincipes: Wat is e-mailverificatie?
• Verbind MCP van een ondersteunde client: MCP-overzicht
• Ga dieper in op de setup: MCP-gids
• Stel Claude Code specifiek in: Claude Code-gids
• 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.