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
- Masowa weryfikacja poczty elektronicznej
- Czym jest weryfikacja poczty elektronicznej?
- Przegląd MCP
- Przewodnik dla deweloperów MCP
- Przewodnik Claude Code
- Dokumentacja API
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_progresschunk_progressprogress_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_sourcemoż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.