Aktualizacja produktu: Lepsza usabilność weryfikacji masowej, bardziej szczera asynchroniczna progress, i nowoczesny model połączenia MCP

W ciągu ostatniego cyklu wydawniczego wprowadziliśmy zestaw zmian, które wszystkie wskazują w tym samym kierunku: ułatwiać ufanie BillionVerify, łatwiej monitorować i łatwiej integrować.

Niektóre z tych zmian są natychmiast widoczne w produkcie. Doświadczenie Bulk Verify jest czystsze po przesłaniu pliku. Strona historii weryfikacji jest bardziej przydatna, podczas gdy zadanie jest jeszcze uruchomione. Wskaźniki postępu teraz odzwierciedlają to, na czym naprawdę zależy użytkownikom, zamiast ujawniać wewnętrzną mechanikę kolejki.

Niektóre ze zmian są głębsze. Umowa stanu weryfikacji za interfejsem użytkownika jest bogatsza i bardziej wyraźna. Model danych teraz rozróżnia postęp na poziomie poczty elektronicznej od postępu wykonywania zaplecza, co daje klientom znacznie lepszą podstawę do renderowania uczciwego stanu w czasie rzeczywistym.

A niektóre ze zmian dotyczą bezpośrednio programistów. BillionVerify MCP w pełni odszedł od starszej konfiguracji ?api_key= i przeszedł do hostowanego zdalnego modelu MCP zbudowanego wokół OAuth, odkrywania chronionych zasobów i nowoczesnej zgodności klientów. Zaktualizowaliśmy produkt, dokumentację, strony marketingowe i powierzchnie uwierzytelniania, aby odpowiadały tej rzeczywistości.

Ten post łączy te aktualizacje w jedną narrację, aby klienci, programiści i wewnętrzne zespoły mogły zobaczyć, jak się one dopasowują.

Jeśli chcesz wersję skróconą, oto ona:

Weryfikacja zbiorcza ma teraz czystszy przepływ po przesłaniu.
Monitorowanie asynchronicznych zadań jest bardziej informacyjne i bardziej uczciwe.
Interfejs stanu zaplecza jest lepiej strukturyzowany dla pracy rozproszonej.
BillionVerify MCP ma teraz wyraźniejszy kształt długoterminowy: zdalny punkt końcowy plus OAuth, a nie klucze API osadzone w URL.

Jeśli chcesz pełną historię, czytaj dalej.

Szybkie Linki

Dlaczego te aktualizacje idą razem

Na pierwszy rzut oka ta wersja wygląda jak kilka oddzielnych wątków:

czyszczenie interfejsu na stronie weryfikacji hurtowej
bogatszy ekran szczegółów historii
ulepszenie umowy statusu backendu
czyszczenie uwierzytelniania MCP i dokumentacji

Ale temat przewodni jest taki sam we wszystkich: usunąć niejasności.

Niejasności pojawiają się na różne sposoby w produktach programowych.

Czasami wygląda to jak zduplikowany interfejs po przesłaniu pliku. Użytkownicy nie są pewni, który przycisk ma znaczenie, jaki jest najlepszy następny krok, czy system wciąż pracuje w tle.

Czasami wygląda to jak pasek postępu, który mówi „29% ukończone", podczas gdy otaczające liczby nie wyjaśniają, co ten procent reprezentuje. Czy to 29% przetworzonych e-maili? 29% ukończonych zadań pracownika? 29% scalonych wyników? Większość użytkowników nie chce dekodować architektury kolejki tylko po to, aby monitorować zadanie.

Czasami niejasność dotyczy wdrażania dla deweloperów. Produkt może już wspierać jedną architekturę w produkcji, podczas gdy części jego publicznej dokumentacji nadal sugerują starszy model połączenia. To powoduje błędy instalacji, zamieszanie i niepotrzebny brak zaufania.

Ta wersja to nasza odpowiedź na te problemy.

Zacisnęliśmy UX produktu wokół tego, co użytkownicy faktycznie muszą wiedzieć. Zacisnęliśmy interfejsy backendu wokół tego, co klienci faktycznie muszą renderować. I zacisnęliśmy historię MCP skierowaną do deweloperów wokół tego, jak platforma faktycznie działa dzisiaj.

1. Bulk Verify ma teraz czystsze doświadczenie po przesłaniu pliku

Pierwsza część tej wersji skupiła się na momencie zaraz po wysłaniu pliku.

Ten moment jest ważniejszy niż się wydaje.

Gdy ktoś przesyła duży plik CSV do weryfikacji, nie jest gotów. Właśnie przeszedł ze stanu wprowadzania danych do stanu monitorowania. Interfejs musi pomóc mu odpowiedzieć na kilka natychmiastowych pytań:

Czy mój plik został pomyślnie przesłany?
Czy przetwarzanie już się rozpoczęło?
Gdzie mogę monitorować to konkretne zadanie?
Czy mogę zaufać, że system powiadomi mnie, gdy się skończy?

Poprzedni przepływ odpowiadał na te pytania, ale robił to ze zbyt dużą powtarzalnością. Karta sukcesu, otaczający ją tekst stanu i dostępne przyciski wszystkie przyciągały uwagę w nieco innych kierunkach.

Wyczyściliśmy to.

Co się zmieniło na stronie

Stan pomyślnego przesłania jest teraz bardziej zwarty i łatwiejszy do skanowania. Ikona sukcesu i tytuł zajmują mniej miejsca w pionie, co daje więcej miejsca dla szczegółów, które użytkownicy faktycznie mają na myśli: nazwa pliku, liczba wiadomości e-mail, szacunkowy czas przetwarzania i następna czynność.

Postęp na żywo jest również wyświetlany domyślnie po przesłaniu. Użytkownicy nie muszą już wykonywać dodatkowego kroku, aby ujawnić te informacje. Jeśli zadanie się wykonuje, strona powinna to pokazać natychmiast.

Główny CTA po przesłaniu również zmienił się w ważny sposób. Zamiast wysyłać użytkowników do ogólnego indeksu historii, działanie główne teraz łączy się bezpośrednio na dokładną stronę szczegółów zadania. Brzmi to jak małą zmianę, ale usuwa niepotrzebny krok i sprawia, że przepływ pracy wygląda znacznie bardziej świadomy.

Usunęliśmy również elementy, które były technicznie funkcjonalne, ale nie były znacząco przydatne:

duplikat tekstu stanu w obszarze przesyłania
dodatkowy przycisk "Prześlij inny plik" na karcie sukcesu

Użytkownicy wciąż mogą przesłać inny plik z głównej powierzchni przesyłania. Różnica polega na tym, że interfejs już się z sobą nie konkuruje.

Dlaczego to ma znaczenie w praktyce

Weryfikacja zbiorcza jest często używana w powtarzających się, operacyjnych przepływach pracy. Użytkownicy mogą przesyłać wiele plików dziennie, monitorować kilka zadań w sesji roboczej i powrócić później, aby pobrać filtrowane wyniki. W takim środowisku nawet małe fragmenty duplikacji UI się sumują.

Czyszczenie stanu po przesłaniu pomaga na trzy sposoby:

Zmniejsza ilość parsowania ekranu wymaganego zaraz po przesłaniu.
Czyni następny krok oczywistym.
Utrzymuje interfejs wyrównany z mentalnym modelem użytkownika: "Mój plik jest w. Teraz chcę śledzić to zadanie."

To jest rodzaj ulepszenia, które rzadko tworzy efektowny zrzut ekranu samodzielnie, ale sprawia, że produkt czuje się spokojniejszy i bardziej spójny każdego dnia.

Przykład: nowa ścieżka po przesłaniu

Oto zamierzona podróż użytkownika teraz:

Prześlij plik CSV w przepływie weryfikacji zbiorczej.
Zobacz natychmiastowy stan sukcesu z nazwą pliku, liczbą wierszy i ETA.
Zobacz postęp na żywo bez konieczności ręcznego ujawniania go.
Kliknij jeden główny przycisk, aby otworzyć dokładną stronę szczegółów historii dla tego zadania.
Wróć później za pośrednictwem e-maila lub historii, aby przejrzeć wyniki i eksporty.

To jest prostszy ścieżka niż:

Prześlij plik.
Analizuj duplikat obszarów stanu.
Kliknij w historię ogólną.
Znajdź prawidłowy wiersz.
Otwórz ponownie docelowe zadanie.

Zmniejszenie wysiłku jest małe w jednej sesji i znaczące przy wielokrotnym użytkowaniu.

2. Historia weryfikacji teraz zachowuje się jak prawdziwa powierzchnia monitorowania

Druga główna poprawa miała miejsce na asynchronicznej stronie historii weryfikacji.

Ta strona kiedyś była funkcjonalna, ale skromna. Mogła pokazać, że zadanie istnieje i że jest w trakcie przetwarzania, ale nie wyglądała jeszcze jak powierzchnia zaprojektowana do aktywnego monitorowania.

To jest niezgodność dla długotrwałego zadania weryfikacji.

Kiedy klient otwiera stronę szczegółów historii podczas przetwarzania pliku, nie szuka tylko liczby procentowej. Próbuje zrozumieć:

do jakiego pliku odnosi się to zadanie
jak duże jest obciążenie pracą
ile pracy zostało już ukończone
jak wygląda wczesny rozkład wyników
jak długo będzie trwać zadanie

Przeprojektowaliśmy stronę zgodnie z tą rzeczywistością.

Stabilne metadane pojawiają się teraz na początku

Zaktualizowana strona historii rozpoczyna się teraz od stabilnej karty podsumowania. Ta karta zawiera najważniejsze metadane zadania:

oryginalną nazwę pliku
całkowitą liczbę wierszy
liczbę unikalnych adresów email
szacunkowy czas przetwarzania
czas rozpoczęcia

Te informacje nie zależą od pętli ankietowania w czasie rzeczywistym. To jest ważne, ponieważ stabilny kontekst powinien pojawić się jak najszybciej, nawet jeśli dynamiczny ładunek statusu nadal się rozmieszcza lub aktualizuje.

Gdy użytkownicy wylądują na stronie, mogą się natychmiast zorientować zamiast czekać, aż odpowiedź na żywy status dokona całą pracę.

Obszar postępu na żywo jest znacznie bogatszy

Poniżej podsumowania doświadczenie w stanie działającym jest teraz znacznie lepsze.

Zamiast zwykłego paska postępu z ograniczonym kontekstem, strona teraz wyświetla:

przetworzoną objętość
pozostałą objętość
rozkład wyników w statusach
semantykę języka i ETA, która odpowiada głównemu przepływowi weryfikacji zbiorczej

Co równie ważne, usuwa metryki wewnętrzne, które powinny pozostać wewnętrzne. Celowo przestaliśmy ujawniać liczby zadań pracownika i fragmentów na powierzchni widocznej dla użytkownika. Te wartości mogą być operacyjnie przydatne, ale nie o to chodzi klientom, gdy pytają: „Jak daleko zaawansowane jest moje zadanie?"

Prawidłowe pytanie prawie zawsze dotyczy poczty elektronicznej, a nie kolejki.

Narzędzia stanu zakończenia pozostają nienaruszone

Jednym z ograniczeń projektowych dla tej pracy było to, że nie chcieliśmy stracić głębi analitycznej ukończonej strony zadania.

Dlatego zachowaliśmy istniejący wykres podziału wyników i narzędzia eksportu. Aktualizacja nie polegała na zastąpieniu doświadczenia stanu zakończenia. Chodziło o wzmocnienie górnej części strony i uczynienie doświadczenia stanu działającego godnym przepływu pracy.

Oznacza to, że strona teraz lepiej wykonuje obie prace:

podczas przetwarzania działa jako powierzchnia monitorowania
po ukończeniu wciąż działa jako powierzchnia analizy i eksportu

Przykład: co użytkownicy mogą teraz szybko zrozumieć

Strona zadania w trakcie działania odpowiada teraz szybko na wszystkie z nich:

„To jest plik z 19 293 wierszami, który przesłałem wcześniej."
„Jest w nim 19 010 unikalnych adresów email."
„System szacuje około 33 minut."
„499 adresów email zostało już zweryfikowanych."
„Większość ukończonego zestawu do tej pory jest ważna, z mniejszym udziałem nieprawidłowych i nieznanych."

To jest znacznie bardziej użyteczny model myślenia niż jedna liczba procentowa o niejasnej semantyce.

3. Semantyka postępu jest teraz bardziej uczciwa

Jedna z największych lekcji w produktach asynchronicznych to to, że "postęp" nie jest pojedynczą koncepcją.

W systemie rozproszonym istnieje kilka rzeczy, które mogą poruszać się niezależnie:

zadania worker mogą się ukończyć
chunki mogą się łączyć
wyniki na poziomie e-maila mogą się akumulować
pliki końcowe mogą stać się dostępne do pobrania

Jeśli klient otrzymuje tylko jedno ogólne pole progress, musi zgadywać, które z tych znaczeń nosi ta liczba. W ten sposób dochodzimy do stanów UI, które są technicznie spójne, ale doświadczeniowo mylące.

Chcieliśmy to naprawić na poziomie kontraktu.

Główna zmiana

Zaktualizowany interfejs umożliwia rozróżnienie między:

email_progress
chunk_progress
progress_source

To rozróżnienie daje klientom znacznie silniejszą bazę do renderowania postępu w sposób odpowiadający intencjom użytkownika.

Na przykład:

duży pasek postępu widoczny dla użytkownika może teraz priorytetyzować email_progress
widoki operacyjne lub diagnostyczne mogą nadal używać chunk_progress
jeśli wymagane jest rozwiązanie awaryjne, progress_source może to wyjaśnić

To jest znacznie zdrowszy model niż udawanie, że wszystkie procenty postępu oznaczają to samo.

Przykładowy payload

Oto jaki kształt to umożliwia:

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

Bez potrzeby wiedzy o podstawowym systemie kolejek, klient może podejmować dobre decyzje na podstawie tej odpowiedzi.

To ma znaczenie, ponieważ API nie tylko zwracają dane. Definiują znaczenie.

Dlaczego jest to lepsze dla klientów

Klientom nie zależy, czy worker ukończył 7 z 96 wewnętrznych zadań, jeśli tylko 499 z 19 010 e-maili zostało faktycznie przetworzonych. Ujawnienie złej abstrakcji postępu tworzy zamieszanie, nie pewność.

Poprzez przeniesienie głównego UI w kierunku email_progress, produkt teraz odzwierciedla jednostkę pracy, na której zależy użytkownikom.

Dlaczego jest to lepsze dla zespołów frontend

UI nie musi już wnioskować zbyt wiele z jednego niejasnego pola procentowego.

To zmniejsza całą klasę błędów produktu:

paski postępu, które wydają się zbyt daleko
bloki podsumowania, które są w tyle za głównym procentem
niezręczny tekst statusu, który próbuje wyjaśnić szczegóły implementacji backendu użytkownikom końcowym

Daje to również zespołom frontend czystszy sposób na oddzielenie stabilnych metadanych zadań od zmieniających się danych wykonania, co bezpośrednio prowadzi do następnej części wydania.

4. Kontrakt statusu backendu jest teraz lepiej ustrukturyzowany do pracy rozproszonej

Zmiany frontend nie byłyby stabilne bez ulepszeń kontraktu backendu.

Podjęliśmy tutaj dwie ważne decyzje strukturalne.

Po pierwsze, rozdzieliliśmy stabilne metadane od statusu live

Niektóre pola prawie się nie zmieniają, jeśli w ogóle, po utworzeniu zadania:

nazwa pliku
czas utworzenia
całkowita liczba wierszy
liczba unikalnych adresów email
szacunkowy czas przetwarzania

Inne pola są z natury dynamiczne:

bieżący status
liczba przetworzonych adresów email
live mieszanka wyników
procenty postępu

Próba wpychania obu klas danych przez tę samą ścieżkę sondowania jest częstą przyczyną niezręczności interfejsu użytkownika. Frontend kończy się czekaniem na dane, które powinny być dostępne natychmiast, jednocześnie ponownie żądając stabilnych danych częściej niż potrzebnie.

Nowy model jest czystszy:

stabilne metadane zadania są traktowane jako metadane
live status zadania jest traktowany jako status

To brzmi oczywiste, gdy napiszemy to zwyczajnie, ale ma znaczące skutki dla jakości implementacji.

Strona szczegółów historii może teraz szybko renderować stabilne informacje podsumowania, sondować tylko to, co trzeba zmienić, i utrzymać spokojny interfejs użytkownika podczas wykonywania zadania.

Po drugie, powiększyliśmy samą ładunek statusu

Interfejs statusu w czasie rzeczywistym jest teraz lepiej dostosowany do rozproszonego przetwarzania asynchronicznego, ponieważ niesie bogatszy obraz tego, co się dotychczas stało.

Obejmuje to liczniki takie jak:

przetworzone
prawidłowe
nieprawidłowe
nieznane
ryzykowne
catchall
rola
jednorazowe
użyte kredyty

Te wartości sprawiają, że interfejs jest bardziej użyteczny nie tylko dla powierzchni postępu skierowanych do człowieka, ale także dla automatyzacji i przepływów pracy downstream. Klient, który rozumie bieżącą mieszankę wyników, może podejmować lepsze decyzje dotyczące alertów, powiadomień, eksportów i post-przetwarzania.

Przykład: dlaczego to ma znaczenie poza interfejsem użytkownika

Wyobraź sobie aplikację skierowaną do klientów zbudowaną na bazie BillionVerify, która chce:

pokazywać dystrybucję jakości na żywo podczas uruchamiania listy
powiadomić użytkownika, jeśli zadanie produkuje niezwykle wysoką liczbę nieprawidłowych wyników
oferować filtrowane eksporty, gdy tylko istnieją przydatne zestawy wyników
zasilać pulpit obsługi lub operacji bez konieczności angażowania inżynierii do inspekcji surowego stanu pracownika

Wszystkie te przypadki użycia stają się łatwiejsze, gdy kontrakt statusu backendu jest wyraźny i wystarczająco bogaty.

Dlatego właśnie praca nad interfejsem backendu ma znaczenie nawet wtedy, gdy pierwszą widoczną zmianą jest „pasek postępu wygląda lepiej". Lepszy pasek postępu jest często symptomem lepszego kontraktu.

5. MCP przeszedł w pełni do ery zdalnego OAuth

Ostatnia główna część tej aktualizacji jest skierowana do deweloperów, ale jest jedną z najważniejszych długoterminowych poprawek produktu w tej wersji.

BillionVerify MCP jest teraz prezentowany i dokumentowany w kształcie, w jakim powinien być dla nowoczesnych klientów zdalnych:

hostowany zdalny endpoint
autoryzacja oparta na OAuth
odkrywanie chronionych zasobów
standardowy dostęp za pomocą tokenu Bearer

Endpoint to:

https://mcp.billionverify.com/mcp

To ma znaczenie, ponieważ starsze wzorce konfiguracji mogą się utrzymywać w materiałach publicznych długo po tym, jak platforma wewnętrznie przeszła do przodu. W naszym przypadku niektóre dokumenty i powierzchnie marketingowe wciąż sugerowały, że MCP może być podłączony poprzez klucze API osadzane w URL-u i wrappery curl --stdio.

To nie jest już właściwy kształt dla BillionVerify MCP.

Stary model mentalny

Starszy wzorzec wyglądał mniej więcej tak:

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

Ten model łączy kilka zagadnień w jeden niezręczny krok konfiguracji:

transport
uwierzytelnianie
obsługa tajemnic
zachowanie lokalnego wrappera

Również wysyła niewłaściwy sygnał o tym, jak zdalny hostowany serwer MCP powinien być konsumowany przez nowoczesnych klientów.

Nowy model mentalny

Obecny model jest czystszy.

Dla Claude Code zalecana konfiguracja to:

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

Następnie wewnątrz Claude Code:

/mcp

Stamtąd klient wykonuje przepływ OAuth w przeglądarce.

Dla ChatGPT i innych kompatybilnych zdalnych klientów MCP, właściwym punktem startowym jest po prostu sam endpoint:

https://mcp.billionverify.com/mcp

Klient odkrywa metadane chronionego zasobu, wykonuje przepływ autoryzacji, a następnie używa tokenów dostępu Bearer do uwierzytelnionych połączeń.

Najważniejsze rozróżnienie: autoryzacja MCP nie jest autoryzacją REST

Jednym z powodów, dla których starsze dokumenty wymagały oczyszczenia, jest to, że klucze API nadal mają znaczenie w BillionVerify. Ale nie należą już do historii uruchamiania MCP.

Czyste rozdzielenie to:

REST API używa kluczy API
zdalne MCP używa OAuth

To rozróżnienie jest teraz znacznie bardziej jasne na całej powierzchni produktu.

Jeśli deweloper używa:

ChatGPT
Claude Code
innego klienta zdalnego MCP obsługującego OAuth

powinien użyć ścieżki zdalnego MCP.

Jeśli buduje:

automatyzacja back-to-back
skrypty sterowane kluczami API
klientów, którzy obsługują tylko lokalne stdio plus klucze API

powinien użyć referencji API i przepływu REST.

To nie jest rozróżnienie kosmetyczne. To granica produktu, a dokumentacja powinna to uczynić oczywistym.

6. Dokumentacja publiczna i marketing są teraz zsynchronizowane z produktem

Uaktualnienie architektury rozwiązuje tylko część problemu, jeśli materiały publiczne wciąż opowiadają inną historię.

Dlatego właśnie traktowaliśmy czyszczenie dokumentacji MCP i marketingu jako część tej samej wersji.

Zaktualizowaliśmy:

publiczną stronę MCP
przewodnik MCP
przewodnik Claude Code
punkty wejścia przewodników AI
wielojęzyczne warianty dokumentacji
zlokalizowaną kopię FAQ marketingu

Cel był prosty: powinna być jedna jasna odpowiedź na pytanie „Jak połączyć BillionVerify MCP?"

Teraz jest.

Dlaczego to ma znaczenie dla programistów

Gdy dokumentacja publiczna pozostaje w tyle za rzeczywistością implementacji, programiści płacą cenę na trzy sposoby:

Nieudane próby konfiguracji
Utrata zaufania do platformy
Dodatkowe obciążenie wsparcia, aby wyjaśnić, co powinno być oczywiste

Dopasowując publiczną powierzchnię do faktycznego modelu zdalnego OAuth, zmniejszamy niepotrzebne tarcie, zanim stanie się to problemem wspierającym.

Dlaczego to ma znaczenie dla pozycjonowania platformy

Ekosystem MCP rozwija się szybko. Gdy coraz więcej zespołów ocenia narzędzia poprzez ChatGPT, Claude Code i innych klientów AI, jakość pierwszego doświadczenia integracyjnego ma większe znaczenie.

Produkt, który wygląda nowocześnie na poziomie protokołu, ale przestarzale w swoim publicznym przewodniku konfiguracji, budzi wątpliwości dokładnie tam, gdzie powinien budować zaufanie.

Dlatego właśnie wzmocniliśmy również powierzchnie logowania i zgody poprzez jaśniejsze Warunki, Politykę prywatności i widoczność kontaktu z pomocą techniczną. Recenzenci, programiści i oceniający przedsiębiorstwa czerpią korzyści, gdy sygnały zaufania są jawne.

7. Praktyczne spojrzenie na wydanie sprzed i po

Jednym z przydatnych sposobów zrozumienia wydania jest porównanie doświadczenia użytkownika i dewelopera przed i po.

Przed

Plik weryfikacji masowej można było przesłać pomyślnie, ale stan po przesłaniu nadal zawierał zduplikowany interfejs i mniej oczywiste następne kroki.
Strona szczegółów historii wyświetlała aktywność, ale nie była jeszcze pełną powierzchnią monitorowania.
Wartość procentu ukończenia mogła istnieć bez wyraźnego poinformowania użytkowników, czy reprezentowała przetworzone wiadomości e-mail czy wewnętrzne zakończenie zadań.
Materiały publiczne MCP nadal częściowo odzwierciedlały starszą historię konfiguracji ?api_key=.

Po

Doświadczenie po przesłaniu jest czystsze, bardziej zwarte i bardziej bezpośrednie.
Postęp na żywo pojawia się domyślnie w przepływie masowym.
Główna CTA po przesłaniu kieruje użytkowników bezpośrednio na dokładną stronę szczegółów zadania.
Strony szczegółów historii wyświetlają stabilne metadane podsumowania oraz bogatszą widoczność wyników na żywo.
Postęp widoczny dla użytkownika skupia się teraz na semantyce postępu na poziomie wiadomości e-mail.
Liczniki wewnętrznych zadań nie są już ujawniane jako metryki widoczne dla klientów.
Interfejs stanu zaplecza jest lepiej ustrukturyzowany dla klientów czasu rzeczywistego i rozproszonych zadań.
Materiały publiczne MCP teraz konsekwentnie odzwierciedlają zdalną architekturę OAuth.

To nie jest jedna funkcja. To znacząca poprawka jakości w całym przepływie pracy.

8. Co to oznacza dla różnych odbiorców

Dla zespołów operacyjnych i wzrostu

Uzyskujesz płynniejszy przepływ pracy weryfikacji zbiorczej z mniejszym tarciem interfejsu użytkownika, lepszą widoczność podczas wykonywania zadań oraz jaśniejszy dostęp do dokładnie uruchomionego zadania.

Dla zespołów produktowych i frontendowych

Masz teraz silniejszą semantykę postępu i czystsze rozdzielenie między metadanymi a stanem na żywo, co ułatwia budowanie ekranów obciążonych postępem i łatwiejsze wyjaśnianie.

Dla zespołów backendowych i platformowych

Masz silniejszą umowę dotyczącą stanu dla rozproszonej weryfikacji i jaśniejszą historię na temat tego, co różne wartości postępu faktycznie oznaczają.

Dla programistów integrujących MCP

Masz teraz znacznie jaśniejszą odpowiedź na pytanie dotyczące konfiguracji: użyj zdalnego MCP plus OAuth dla klientów MCP i użyj kluczy API dla REST API, gdzie ten model jest odpowiedni.

9. Od czego zacząć

Jeśli chcesz poznać zaktualizowaną funkcjonalność lub ścieżki integracji, zacznij tutaj:

Dowiedz się więcej o produkcie: Weryfikacja e-maili
Uruchamiaj większe przepływy pracy: Zbiorcza weryfikacja e-maili
Zrozum fundamenty: Co to jest weryfikacja e-maili?
Połącz MCP z obsługiwanego klienta: Przegląd MCP
Pogłęb wiedzę na temat konfiguracji: Poradnik MCP
Skonfiguruj Claude Code: Poradnik Claude Code
Użyj integracji opartej na kluczu API: Dokumentacja API

Zamknięcie

Ta wersja nie dotyczyła jednej dużej, efektownej powierzchni. Chodziło o zaciśnięcie produktu, gdzie pojawiła się niejasność.

Uczyniliśmy podróż weryfikacji zbiorczej czystszą. Uczyniliśmy monitoring asynchroniczny bardziej przydatnym. Uczyniliśmy raportowanie postępu bardziej szczerym. I uczyniliśmy historię MCP zgodną z platformą, którą faktycznie budujemy.

Te ulepszenia wzmacniają się nawzajem.

Produkt staje się łatwiejszy do zaufania, gdy interfejs użytkownika mówi mniej, ale znaczy więcej. Staje się łatwiejszy do integracji, gdy dokumentacja opisuje rzeczywistą architekturę. I staje się łatwiejszy do ewolucji, gdy interfejsy poniżej doświadczenia noszą wyraźniejszą semantykę.

To kierunek, w którym nadal napędzamy BillionVerify.

Jeśli już używasz BillionVerify, te zmiany powinny sprawić, że Twój codzienny przepływ pracy będzie bardziej bezpośredni i bardziej przewidywalny.

Jeśli teraz oceniasz platformę, ta aktualizacja jest dobrą migawką tego, jak myślimy o jakości produktu: przejrzystość skierowana do użytkownika na wierzchu, jawne kontrakty poniżej, i dokumentacja, która odpowiada rzeczywistości.