Bird vs Prelude
Bird vs Prelude untuk Verify
Bird Verify menyediakan pengiriman berbasis penerima dan pemeriksaan kode: buat kode, lanjutkan rencana kanal yang tersedia, dan periksa jawaban menggunakan penerima yang sama. Bandingkan alur tersebut dengan jendela verifikasi dan hasil risiko Prelude sebelum memindahkan proses pendaftaran atau login.
Dipercaya setiap hari oleh tim yang
membangun perangkat lunak kelas dunia.
Alur verifikasi mana yang cocok untuk aplikasi Anda?
Kapan Prelude cocok
Respons create Prelude membedakan success, retry, challenged, blocked, dan shadow_blocked. Sinyalnya mendukung keputusan penipuan; challenged dan shadow_blocked memerlukan pengaktifan akun. Pertahankan atau ganti keputusan risiko yang diandalkan aplikasi Anda sebelum memindahkan pengiriman kodenya.
Prelude mendokumentasikan RCS, Viber, Zalo, dan autentikasi jaringan senyap di samping SMS, WhatsApp, dan Telegram; metode permintaannya juga menerima voice. Paket yang dapat dipilih dari Bird mencakup SMS, WhatsApp, email, dan Telegram. Voice masih dalam tahap peluncuran dan belum tersedia sebagai opsi migrasi pelanggan. Pertahankan atau rancang ulang metode RCS, Viber, Zalo, atau autentikasi senyap yang Anda andalkan.
Opsi permintaan Prelude mencakup template, locale, dan sender ID yang diaktifkan. Kode kustom, daftar kanal eksplisit, force_challenge, dan max_auto_fallbacks memerlukan pengaktifan akun. Pengaturan tersebut memerlukan keputusan migrasi eksplisit, bukan sekadar penggantian nama field.
Mengapa memilih Bird Verify?
Bird mengidentifikasi verifikasi berdasarkan penerima, termasuk alamat email, nomor telepon, atau keduanya. Rencana negaranya menentukan kanal mana yang tersedia; options.channels dapat memangkas atau mengurutkan ulang rencana tersebut.
Respons check Bird mengembalikan success, reason, dan attempts_remaining. Simpan success: true di aplikasi Anda; pemeriksaan berikutnya pada verifikasi yang sudah final mengembalikan 404 dan tidak membatalkan hasil tersebut.
Server MCP yang di-host Bird dan contoh CLI menjalankan operasi create, check, dan next-channel. Agen dapat meminta kanal pengiriman berikutnya dengan penerima yang sama yang sudah dimiliki aplikasinya.
Matriks
Bagaimana perbandingan Verify API?
Bandingkan status penerima, pemulihan, dan keputusan risiko. Ketersediaan kanal dan opsi lanjutan bergantung pada tujuan dan pengaktifan akun.
| Kemampuan | Bird | Prelude | Siapa yang menang? |
|---|---|---|---|
| Request create | JSON dengan bearer key ke /v1/verify/verifications, dengan to.email, to.phone_number, atau keduanya. | JSON create-or-retry dengan bearer key dan target.type ditambah target.value. Verifikasi email memerlukan menghubungi Prelude terkait kasus penggunaannya. | |
| Pengulangan aman | Idempotency-Key mengulang permintaan. Pengiriman ulang penerima menggunakan kembali verifikasi aktif, mematuhi cooldown-nya, dan mengirim kode baru setelahnya. | Mengulangi permintaan dalam jendela verifikasi aktif membuat percobaan retry. Panduan siklus hidup mendokumentasikan jarak retry minimum dan batas percobaan. | |
| Apa yang ditunjukkan pemeriksaan gagal | success: false, reason, dan attempts_remaining. Simpan hasil yang berhasil sebelum verifikasi diselesaikan. | Status check mencakup success, failure, dan expired_or_not_found. Kode yang terikat transaksi juga dapat mengembalikan transaction_missing atau transaction_mismatch. | |
| Channel tempat kode sandi bisa diterima | SMS, WhatsApp, email, dan Telegram, dibatasi sesuai paket negara penerima yang ditentukan. Voice masih dalam tahap peluncuran dan belum tersedia untuk lalu lintas pelanggan. | Kanal pesan mencakup SMS, RCS, WhatsApp, Telegram, Viber, dan Zalo, ditambah silent authentication; method: voice meminta panggilan telepon. Ketersediaan bergantung pada akun dan tujuan. | |
| Event pengiriman | Langganan workspace membedakan event verifikasi dan pengiriman; tanda tangan Standard Webhooks mengautentikasi payload. | options.callback_url memilih tujuan per permintaan. Buat signing key untuk mengaktifkan tanda tangan RSASSA-PSS SHA-256 di X-Webhook-Signature. | |
| Kontrol fallback | Kegagalan pengiriman memajukan rencana yang diselesaikan. Next-channel memajukannya berdasarkan permintaan dan mengirim kode baru; kode sebelumnya tetap berlaku. | max_auto_fallbacks membatasi percobaan otomatis tambahan dan memerlukan pengaktifan akun. Nilainya ditetapkan saat pembuatan; retry yang diminta mendapat jatah baru dari batas yang sama. | |
| Server MCP ter-host | MCP yang di-host dan terautentikasi menjalankan create, check, dan next-channel; CLI bird menyediakan operasi yang sama. | SDK backend Prelude memungkinkan kode aplikasi memanggil Verify. Node SDK)-nya menyediakan verification.create dan verification.check. | |
| Panjang kode | options.code_length memilih panjang kode; jika tidak, pengaturan workspace yang berlaku. | options.code_size menerima 4 hingga 8 digit dan jika tidak menggunakan pengaturan dashboard. | |
| Hasil risiko | Batas pengiriman penerima, batas pemeriksaan, dan konfigurasi negara. Respons create mengembalikan verifikasi, tanpa hasil challenged atau shadow_blocked milik Prelude. | Status create dan data risiko mendukung percabangan pada lalu lintas yang diblokir. reason menjelaskan pemblokiran; risk_factors muncul untuk keputusan blocked atau shadow_blocked ketika sinyal risiko tertentu terdeteksi; field tersebut bukan alasan untuk setiap pengiriman yang berhasil. |
Siapa yang mengendalikan percobaan pengiriman berikutnya?
Bird menyelesaikan rencana kanalnya dari penerima dan negara. Kegagalan pengiriman atau permintaan next-channel eksplisit memajukan rencana tersebut. Setiap pemanggilan eksplisit memajukan paling banyak satu kanal dan mengirim kode baru; kode sebelumnya tetap berlaku untuk verifikasi aktif.
Bird: create dengan to → rencana kanal yang diselesaikan → pengiriman gagal atau next-channel → kode baru → check dengan to yang sama. Rencana yang habis mengembalikan NoNextChannel. Catat keberhasilan sebelum menawarkan pengiriman lain.
Prelude: create dengan target dan signals → hasil risiko → jendela verifikasi → rute pengiriman → retry otomatis atau diminta → pemeriksaan kode. Panduan siklus hidupnya memperlakukan create lain untuk nomor yang sama dalam jendela aktif sebagai retry, bukan verifikasi baru.
Batas fallback Prelude menghitung percobaan otomatis tambahan. Nilai nol menonaktifkan retry provider dan kanal otomatis. Nilainya memerlukan pengaktifan dan ditetapkan saat pembuatan; mengubahnya pada retry diabaikan, sedangkan retry yang diminta mendapat jatah baru dari batas yang ditetapkan.
Apa arti success di setiap respons?
Endpoint check Bird mengembalikan success: true ketika kode diterima. HTTP 200 juga dapat mengembalikan success: false dan alasan kegagalan. Pertahankan hasil aplikasi yang berhasil; 404 dari catatan yang sudah final bukan pembatalan autentikasi.
Status create Prelude: success berarti jendela verifikasi baru telah dibuat. Status check: success)-nya adalah hasil yang digunakan untuk penerimaan kode. Jangan berikan akses dari hasil create. Kedua panggilan mengidentifikasi target berdasarkan type dan value.
Referensi check Prelude juga mendefinisikan transaction_missing dan transaction_mismatch untuk kode prelude:psd2. Pertahankan pengikatan transaksi tersebut atau pilih pengganti eksplisit sebelum memigrasikan alur seperti itu.
Sinyal risiko dan pemeriksaan webhook mana yang harus bertahan saat migrasi?
Prelude mendefinisikan dispatch_id sebagai “The identifier of the dispatch that came from the front-end SDK.” di referensi create. Berikan nilai dispatch aktual dari SDK saat menggunakan integrasi tersebut; UUID permintaan yang dibuat aplikasi bukan pengganti.
Panduan fraud Prelude menjelaskan sinyal yang disediakan server dan sinyal perangkat tambahan dari SDK frontend-nya. Status challenged dan shadow_blocked memerlukan pengaktifan akun. Inventarisasi cabang aplikasi yang mengonsumsi hasil tersebut.
Batas kirim dan periksa Bird membatasi penggunaan API. Batas tersebut tidak menggantikan keputusan risiko yang menjadi dependensi alur pendaftaran Anda. Pertahankan keputusan fraud aplikasi di sekitar pengiriman kode.
Prelude menandatangani payload webhook dengan RSASSA-PSS dan SHA-256 setelah kunci penandatanganan dibuat di dashboard-nya. Bird menggunakan Standard Webhooks. Pertahankan verifikasi tanda tangan, tetapi ganti verifier dan pemetaan event alih-alih menggunakan ulang logika header Prelude.
Bagaimana verifikasi dan pengiriman ditagih?
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
| Item yang dipublikasikan | Prelude | Kebijakan penagihan 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. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. |
| 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. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. |
| Enterprise Custom volume | Contact sales Contact sales for committed volume pricing. as published | There's no plan, seat, or platform fee for Bird Verify. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. |
| 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. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. |
| 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. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. |
| 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. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. 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. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. |
| 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. Pengiriman melalui kanal ditagih terpisah. Periksa tarif kanal terkini di bawah. This method is outside Bird’s documented Verify channel plan. |
Bird mempublikasikan tarif kanal 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.
| Tujuan | Jenis pengirim | Per segmen 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.
Verifikasi yang sama
Bagaimana cara memulai verifikasi?
Resource create Prelude menerima target dan options.code_size di /v2/verification. Endpoint create Bird menerima to dan options.code_length. Berikan identifier dispatch frontend yang asli hanya saat integrasi Prelude tersebut sedang digunakan.
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);
Biaya peralihan
Apa yang harus diubah sebelum cutover?
Inventarisasi metode, keputusan risiko, template, sender ID, dan pemeriksaan terikat transaksi yang digunakan aplikasi Anda. Panduan migrasi Prelude memetakan field yang didukung. Jalur voice, RCS, Viber, Zalo, atau autentikasi senyap yang Anda andalkan memerlukan alternatif eksplisit sebelum dipindahkan ke Bird.
Arahkan create baru ke penyedia yang dipilih dan pertahankan check yang tertunda di penyedia yang menerbitkan kode. Petakan event callback, pasang signature verifier yang sesuai, dan simpan check yang berhasil. Uji timeout retry, pengiriman ulang oleh pengguna, perpindahan channel, dan verifikasi kedaluwarsa sebelum cutover. Tinjau kebijakan pengirim dan pesan Bird dengan alur yang dilihat penerima.
Apa yang harus Anda periksa sebelum memilih?
Apakah Bird merupakan alternatif Prelude untuk SMS dan email?
Apakah retry memulai verifikasi Prelude baru?
Bisakah saya menyesuaikan batas fallback Prelude pada setiap retry?
Apa yang harus saya simpan setelah check berhasil?
Terapkan dalam praktik.
Lanjutkan dengan dokumentasi, panduan, dan contoh untuk topik ini. Sumber daya tersedia dalam bahasa Inggris.
Langkah selanjutnya
Mulai dengan panduan migrasi, lalu bandingkan channel yang didukung dan unit penagihan.
Jadikan verifikasi bagian dari produk Anda.
Diskusikan channel, alur verifikasi, dan perkiraan lalu lintas Anda bersama tim kami.