Bird kontra Prelude
Bird kontra Prelude — weryfikacja
Bird Verify udostępnia dostarczanie i sprawdzanie kodów na podstawie odbiorcy: utwórz kod, przejdź do następnego kanału w planie i sprawdź odpowiedź, używając tego samego odbiorcy. Porównaj ten przepływ z oknem weryfikacji i wynikami oceny ryzyka Prelude przed migracją rejestracji lub logowania.
Zaufanie zespołów, które każdego dnia
tworzą oprogramowanie światowej klasy.
Który przepływ weryfikacji pasuje do Twojej aplikacji?
Kiedy Prelude pasuje
Odpowiedź create Prelude rozróżnia statusy success, retry, challenged, blocked i shadow_blocked. Jego sygnały zasilają decyzje dotyczące oszustw; challenged i shadow_blocked wymagają aktywacji konta. Zachowaj lub zastąp decyzję o ryzyku, na której opiera się Twoja aplikacja, zanim przeniesiesz dostarczanie kodów.
Dokumentacja Prelude opisuje RCS, Viber, Zalo i cichą autoryzację sieciową obok SMS, WhatsApp i Telegram; jego metoda żądania akceptuje też połączenia głosowe. Konfigurowalny plan Bird obejmuje SMS, WhatsApp, e-mail i Telegram. Kanał głosowy jest wciąż wdrażany i nie stanowi opcji migracji klientów. Zachowaj lub przeprojektuj używaną metodę RCS, Viber, Zalo lub cichej autoryzacji sieciowej.
Opcje request Prelude obejmują szablony, locale i włączony sender ID. Niestandardowe kody, jawna lista kanałów, force_challenge i max_auto_fallbacks wymagają aktywacji konta. Te ustawienia wymagają świadomej decyzji migracyjnej, a nie zmiany nazwy pola.
Dlaczego wybrać Bird Verify?
Bird identyfikuje weryfikację po odbiorcy, w tym adresie e-mail, numerze telefonu lub obu. Plan dla danego kraju określa dostępne kanały; options.channels może przyciąć lub zmienić kolejność tego planu.
Odpowiedź check Bird zwraca success, reason i attempts_remaining. Zapisz success: true w swojej aplikacji; późniejsze sprawdzenie sfinalizowanej weryfikacji zwraca 404 i nie cofa tego wyniku.
Hostowany serwer MCP Bird i przykłady CLI obsługują operacje create, check i next-channel. Agent może zażądać następnego kanału dostarczania, używając tego samego odbiorcy, którego już posiada jego aplikacja.
Macierz porównawcza
Jak wypadają Verify API w porównaniu?
Porównaj stan odbiorcy, odzyskiwanie i decyzje o ryzyku. Dostępność kanałów i zaawansowane opcje zależą od miejsca docelowego i aktywacji konta.
| Funkcja | Bird | Prelude | Kto wygrywa? |
|---|---|---|---|
| Żądanie create | JSON z kluczem bearer do /v1/verify/verifications, z to.email, to.phone_number lub oboma. | JSON create-or-retry z kluczem bearer oraz target.type i target.value. Weryfikacja e-mail wymaga kontaktu z Prelude w sprawie przypadku użycia. | |
| Bezpieczne ponowienia | Idempotency-Key powtarza żądanie. Ponowne wysyłki do odbiorcy wykorzystują aktywną weryfikację, respektują jej cooldown i wysyłają nowy kod po jego upływie. | Powtórzenie żądania w ramach aktywnego okna weryfikacji tworzy próbę retry. Przewodnik cyklu życia dokumentuje minimalny odstęp między próbami i limity prób. | |
| Co mówi nieudana weryfikacja | success: false, reason i attempts_remaining. Zapisz pomyślny wynik, zanim weryfikacja zostanie sfinalizowana. | Status check obejmuje success, failure i expired_or_not_found. Kody powiązane z transakcją mogą też zwracać transaction_missing lub transaction_mismatch. | |
| Kanały dostarczenia kodu | SMS, WhatsApp, e-mail i Telegram, z ograniczeniem do planu krajowego przypisanego odbiorcy. Połączenia głosowe są wciąż wdrażane i nie są dostępne dla ruchu klientów. | Kanały wiadomości obejmują SMS, RCS, WhatsApp, Telegram, Viber i Zalo, a także cichą autentykację; method: voice żąda połączenia telefonicznego. Dostępność zależy od konta i miejsca docelowego. | |
| Zdarzenia dostarczenia | Subskrypcje obszaru roboczego rozróżniają zdarzenia weryfikacji i dostarczania; sygnatury Standard Webhooks uwierzytelniają payload. | options.callback_url wybiera miejsce docelowe dla każdego żądania. Wygeneruj klucz podpisujący, aby włączyć sygnatury RSASSA-PSS SHA-256 w X-Webhook-Signature. | |
| Kontrola fallbacku | Niepowodzenie dostarczania przesuwa rozwiązany plan. Next-channel przesuwa go na żądanie i wysyła nowy kod; wcześniejsze kody pozostają ważne. | max_auto_fallbacks ogranicza liczbę dodatkowych automatycznych prób i wymaga aktywacji konta. Wartość jest ustalana przy tworzeniu; żądana ponowna próba otrzymuje nową pulę tego samego limitu. | |
| Hostowany serwer MCP | Uwierzytelniony hostowany MCP obsługuje operacje create, check i next-channel; bird CLI udostępnia te same operacje. | Backendowe SDK Prelude pozwalają kodowi aplikacji wywoływać Verify. Node SDK) udostępnia verification.create i verification.check. | |
| Długość kodu | options.code_length wybiera długość kodu; w przeciwnym razie obowiązuje ustawienie obszaru roboczego. | options.code_size przyjmuje od 4 do 8 cyfr, a w przeciwnym razie używa ustawienia z panelu. | |
| Wynik oceny ryzyka | Limity wysyłek do odbiorcy, limity sprawdzeń i konfiguracja krajowa. Odpowiedź create zwraca weryfikację, bez wyniku challenged lub shadow_blocked jak w Prelude. | Status create i dane o ryzyku wspierają rozgałęzienia przy zablokowanym ruchu. reason opisuje blokadę; risk_factors pojawia się dla decyzji blocked lub shadow_blocked, gdy wykryto konkretne sygnały ryzyka; te pola nie stanowią uzasadnienia dla każdego udanego wysłania. |
Kto kontroluje następną próbę dostarczenia?
Bird tworzy plan kanałów na podstawie odbiorcy i kraju. Niepowodzenie dostarczania lub jawne żądanie next-channel przesuwa ten plan. Każde jawne wywołanie przesuwa co najwyżej o jeden kanał i wysyła nowy kod; wcześniejsze kody pozostają ważne dla aktywnej weryfikacji.
Bird: create z to → rozwiązany plan kanałów → niepowodzenie dostarczania lub next-channel → nowy kod → check z tym samym to. Wyczerpany plan zwraca NoNextChannel. Zapisz sukces przed zaproponowaniem kolejnego wysłania.
Prelude: create z target i signals → wynik oceny ryzyka → okno weryfikacji → trasa dostarczania → automatyczna lub żądana ponowna próba → sprawdzenie kodu. Przewodnik cyklu życia traktuje kolejne create dla tego samego numeru w ramach aktywnego okna jako retry, a nie nową weryfikację.
Limit fallbacku Prelude liczy dodatkowe automatyczne próby. Wartość zero wyłącza automatyczne ponowne próby dostawcy i kanału. Wartość wymaga aktywacji i jest ustalana przy tworzeniu; zmiana przy retry jest ignorowana, natomiast żądana ponowna próba otrzymuje nową pulę ustalonego limitu.
Co oznacza success w każdej odpowiedzi?
Endpoint check Bird zwraca success: true, gdy kod zostanie zaakceptowany. HTTP 200 może też zawierać success: false i powód odmowy. Zachowaj pomyślny wynik w aplikacji; 404 dla sfinalizowanego rekordu nie jest cofnięciem uwierzytelnienia.
Status create Prelude: success oznacza, że utworzono nowe okno weryfikacji. Status check: success to wynik, którego należy użyć do akceptacji kodu. Nie przyznawaj dostępu na podstawie wyniku create. Oba wywołania identyfikują cel po jego type i value.
Dokumentacja sprawdzania Prelude definiuje również transaction_missing i transaction_mismatch dla kodów prelude:psd2. Zachowaj to powiązanie transakcji lub wybierz jawny zamiennik przed migracją takiego przepływu.
Które sygnały ryzyka i sprawdzenia webhooków muszą przetrwać migrację?
Prelude definiuje dispatch_id jako “The identifier of the dispatch that came from the front-end SDK.” w swojej dokumentacji tworzenia. Podaj rzeczywistą wartość dispatch SDK, gdy korzystasz z tej integracji; UUID żądania wygenerowany przez aplikację nie jest zamiennikiem.
Przewodnik Prelude po oszustwach opisuje sygnały dostarczane przez serwer oraz dodatkowe sygnały urządzenia z frontendowych SDK. Jego stany challenged i shadow_blocked wymagają aktywacji konta. Zinwentaryzuj gałęzie aplikacji, które wykorzystują te wyniki.
Limity wysyłek i sprawdzeń Bird ograniczają użycie API. Nie zastępują one werdyktu ryzyka, od którego zależy Twój przepływ rejestracji. Zachowaj decyzję aplikacji o oszustwie wokół dostarczania kodu.
Prelude podpisuje payloady webhooków za pomocą RSASSA-PSS i SHA-256 po wygenerowaniu klucza podpisu w panelu. Bird używa Standard Webhooks. Zachowaj weryfikację podpisu, ale zamień weryfikator i mapowanie zdarzeń zamiast ponownie używać logiki nagłówków Prelude.
Jak rozliczana jest weryfikacja i dostarczanie?
There's no plan, seat, or platform fee for Bird Verify. Each delivery is charged at that channel's rate for the destination. A resend, or a fallback that moves delivery to a second channel, is a new send and a new charge.
A verdict compares only published delivery rates with the same channel, destination, currency, billing unit and sender type. Per-success verification fees and per-send charges are Not comparable: your own sends and successful checks determine usage.
Pricing verdict: Not comparable
| Opublikowana pozycja | Prelude | Zasady rozliczeń Bird |
|---|---|---|
| Pay As You Go Per verification | 0.032 € Per verification plus message costs. Monthly billing and 10,000 verifications selected. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. |
| Startup Per month | 360 € Per month plus message costs. Monthly billing and 10,000 verifications selected. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. |
| Enterprise Custom volume | Contact sales Contact sales for committed volume pricing. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. |
| SMS (US) Per SMS Destination: US | €0.0043 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. |
| WhatsApp (US) Per message Destination: US | €0.0028 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. |
| RCS (US) Per message Destination: US | €0.00 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. This method is outside Bird’s documented Verify channel plan. |
| Telegram (US) Per message Destination: US | €0.012 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. |
| Viber (US) Per message Destination: US | €0.007 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Wysyłki kanałowe są rozliczane osobno. Sprawdź aktualne stawki kanałów poniżej. This method is outside Bird’s documented Verify channel plan. |
Bird opublikował stawki kanału SMS
Bird's SMS catalogue rates are shown by sender type, per message segment. Carrier fees and sender costs may apply separately. These channel rates are not a total verification quote. SMS pricing; carrier fees.
| Cel | Typ nadawcy | Za segment SMS |
|---|---|---|
| US | long_code | EUR 0.003 |
| US | long_code | USD 0.0035 |
| US | toll_free | EUR 0.003 |
| US | toll_free | USD 0.0035 |
| US | short_code | EUR 0.006 |
| US | short_code | USD 0.007 |
Bird email pricing and Bird WhatsApp pricing publish the other delivery channels.
Ta sama weryfikacja
Jak rozpocząć weryfikację?
Zasób tworzenia Prelude przyjmuje target i options.code_size pod /v2/verification. Endpoint tworzenia Bird przyjmuje to i options.code_length. Podaj rzeczywisty identyfikator dispatch frontendu tylko wtedy, gdy ta integracja Prelude jest używana.
Prelude
const response = await fetch("https://api.prelude.dev/v2/verification", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.PRELUDE_API_TOKEN}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
target: { type: "phone_number", value: "+15551234567" },
options: { code_size: 6 },
}),
});
const verification = await response.json();
console.log(verification.id, verification.status);
Bird
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const { data, error } = await bird.verify.verifications
.create(
{
to: { phone_number: "+15551234567" },
options: { code_length: 6 },
},
)
.safe();
if (error) console.error(error.message);
else console.log(data.id, data.status);
Koszt migracji
Co trzeba zmienić przed przełączeniem?
Zinwentaryzuj metody, decyzje o ryzyku, szablony, identyfikatory nadawcy i sprawdzenia powiązane z transakcjami, z których korzysta Twoja aplikacja. Przewodnik migracji z Prelude mapuje obsługiwane pola. Używana ścieżka głosowa, RCS, Viber, Zalo lub cichej autoryzacji sieciowej wymaga jawnej alternatywy przed migracją do Bird.
Kieruj nowe tworzenia do wybranego dostawcy i zachowaj oczekujące sprawdzenia u dostawcy, który wydał kod. Zmapuj zdarzenia callback, zainstaluj odpowiedni weryfikator podpisu i utrwal pomyślne sprawdzenia. Przetestuj ponowienia po timeout, ponowne wysyłki użytkownika, awansowanie kanału i wygasłe weryfikacje przed przełączeniem. Przejrzyj politykę nadawcy i wiadomości Bird w kontekście przepływu widocznego dla odbiorcy.
Co sprawdzić przed wyborem?
Czy Bird jest alternatywą dla Prelude w zakresie SMS i e-mail?
Czy ponowienie rozpoczyna nową weryfikację Prelude?
Czy mogę dostosować limit awaryjny Prelude przy każdym ponowieniu?
Co zapisać po pomyślnym sprawdzeniu?
Zastosuj w praktyce.
Kontynuuj z dokumentacją, przewodnikami i przykładami dotyczącymi tego tematu. Zasoby są w języku angielskim.
Co dalej
Zacznij od przewodnika migracji, następnie porównaj obsługiwane kanały i jednostki rozliczeniowe.
Uczyń weryfikację częścią swojego produktu.
Omów z naszym zespołem swoje kanały, przepływ weryfikacji i oczekiwany ruch.