Bird Verify
वह verification API जिसमें store करने के लिए कुछ नहीं।
Email, SMS, या WhatsApp पर एक one-time code भेजें, फिर उसे recipient के आधार पर check करें, दोनों calls के बीच रखने के लिए कोई verification id नहीं। Channel क्रम, sender, और code नियम हर देश के लिए configuration हैं, rebuild नहीं। हर दूसरे Bird channel जैसा ही auth और idempotency, क्योंकि इन सबको एक ही team ने बनाया है। Voice आगे रोल आउट हो रहा है।
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
// Send the code, then check it by recipient.
await bird.verify.verifications.create({
to: { phone_number: "+15551234567" },
}).safe();
const { data } = await bird.verify.verifications.check({
to: { phone_number: "+15551234567" },
code: userInput,
}).safe();
Two calls from npm install to a verified user
एक code भेजें, फिर उसे check करें, उसी भाषा में जो आप पहले से इस्तेमाल करते हैं।
Create-or-retry code भेजता है; check उसे recipient के आधार पर confirm करता है। दो calls, और दोनों के बीच पिरोने के लिए कोई verification id नहीं।
const verification = await bird.verify.verifications.create({
to: { phone_number: "+15551234567" },
});
console.log(verification.id, verification.status);दस चीजें जो आप नहीं बनाते
जब verification ही API हो।
ठोस primitives, नामित और configurable। कोई गोलमोल बात नहीं।
- 01
एक ही call में create या retry।
वही recipient दोबारा post करें और हम live session फिर से शुरू कर देते हैं और cooldown बीतते ही दोबारा भेज देते हैं। कोई अलग resend endpoint नहीं, कोई duplicate verifications नहीं।
- 02
Target के आधार पर check करें। कुछ भी store न करें।
Recipient और code submit करें; हम configuration-और-recipient जोड़ी से session resolve कर लेते हैं। Send और check के बीच persist करने के लिए कोई verification id नहीं होती।
- 03
Launch पर Email, SMS, और WhatsApp।
आप जो recipient देते हैं वही channel चुनता है: एक email address email से verify होता है, एक phone number SMS या WhatsApp से। Channels बदलना एक-field का बदलाव है, नया integration नहीं। Voice आगे रोल आउट हो रहा है, और channels के बीच automatic fallback रास्ते में है।
- 04
Per-country channel क्रम, config के रूप में।
Channel क्रम, sender, और कौन-से channels चालू हैं, हर देश के लिए, एक first-class configuration resource के रूप में सेट करें, न कि support ticket के जरिए।
- 05
वे codes जो आप कभी नहीं देखते।
एक cryptographic random source से generate किए गए, केवल HMAC के रूप में store किए गए, constant time में तुलना किए गए। Plaintext code कभी आपके stack या हमारे logs को नहीं छूता।
- 06
Configurable code, TTL, attempts।
छह-अंकों का default, 4–10 configurable; एक 10-मिनट का window; 5 attempts; एक 60-second resend cooldown, हर configuration के लिए सेट। Code length को हर request के लिए भी override किया जा सकता है।
- 07
हर code session खत्म होने तक valid रहता है।
एक देर से आया message और एक ताजा दोबारा भेजा गया code दोनों verify करते हैं, क्योंकि जब नया code जाता है तब हम पुराने code को invalidate नहीं करते।
- 08
गलत code एक 200 है, exception नहीं।
Check एक boolean result के साथ जवाब देता है — इस code ने verify किया या नहीं, हां या नहीं — और एक reason जो न होने पर विस्तार देता है: invalid, expired, already verified, या attempts खत्म। आप एक field पर branch करते हैं, कभी किसी thrown error पर नहीं।
- 09
Rate limits built in।
Per-recipient send caps और एक per-verification guess limit, हर एक Retry-After के साथ एक 429, ताकि brute force आपसे पहले खत्म हो जाए।
- 10
बाकी Bird जैसा ही contract।
Bearer auth, एक idempotency key, typed vrf_ ids, एक error envelope। जो handler आपने email के लिए लिखा वह verification के लिए पहले से फिट बैठता है।
Verify platform को explore करें
हर capability गहराई से। एक API, keys का एक set।
SMS OTP.
SMS पर one-time passcodes, वैश्विक पहुंच और built-in rate limits के साथ।
Email OTP.
उसी network पर email से verify करें जो पहले से आपका transactional mail ढोता है।
WhatsApp OTP.
उसी plan में एक orderable channel के रूप में WhatsApp पर codes भेजें।
Voice OTP.
रोल आउट हो रहा है: landlines, accessibility, और मुश्किल-से-पहुंचने वाले users के लिए एक बोला जाने वाला code।
Channel orchestration.
Per-country channel क्रम, senders, और enable/disable एक first-class config resource के रूप में।
Anti-abuse & code security.
Hashed codes, per-recipient caps, attempt lockout, और fraud roadmap।
Send और check के बीच कुछ भी store न करें।
ज्यादातर verification APIs आपको एक id देती हैं जिसे persist करना, look up करना, और उसके खिलाफ code submit करना होता है। Bird recipient से session resolve कर लेता है, इसलिए आपकी तरफ कोई per-verification state नहीं होती।
ज्यादातर verification APIs
Create एक id return करता है जिसे आप store करते हैं, फिर उसके खिलाफ code check करने के लिए verification को look up करते हैं।
const { id } = await api.verifications.create({
to: "+15551234567",
});
// persist id somewhere, then later…
await api.verifications.check({ id, code });
Bird Verify
Recipient के आधार पर check करें। दोनों calls के बीच पिरोने के लिए कुछ नहीं।
await bird.verify.verifications.create({
to: { phone_number: "+15551234567" },
}).safe();
// no id to store; check by the same recipient
await bird.verify.verifications.check({
to: { phone_number: "+15551234567" }, code,
}).safe();
Per-country routing configuration है।
Set the channel order, sender, and which channels are on per country: WhatsApp-first in one market, SMS-only in another. It's a first-class config resource, resolved into each verification's plan. See channel orchestration.
await bird.verify.verifications.configurations.countries.upsert(
"vfc_login",
"BR",
{ channels: [
{ channel: "whatsapp", state: "enabled" },
{ channel: "sms", state: "enabled" },
] },
).safe();
Verification एक product निर्णय भी है: वही API two-factor authentication और passwordless login को शक्ति देता है। पहले किसी number को validate कर रहे हैं? इसे Lookup के साथ जोड़ें। Silent network authentication और TOTP authenticator apps roadmap पर हैं।
हम Verify क्यों बनाते हैं
क्योंकि जो code किसी user को अंदर आने देता है उसे अपनी खुद की database table की जरूरत नहीं होनी चाहिए।
OTP वह channel है जहां जो code नहीं पहुंचता वह signup है जो नहीं होता। Bird पहले से email और SMS को scale पर चलाता है, इसलिए Verify वही delivery है और साथ में code generation, session, per-country channel plan, और rate limits, दो endpoints के पीछे जो आपकी तरफ कुछ store नहीं करते और हर दूसरे Bird channel जैसे ही आकार में जवाब देते हैं।
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
// Send the code, then check it by recipient.
await bird.verify.verifications.create({
to: { phone_number: "+15551234567" },
}).safe();
const { data } = await bird.verify.verifications.check({
to: { phone_number: "+15551234567" },
code: userInput,
}).safe();
यदि आपने SMS integrate किया है, तो आपने Verify integrate कर लिया है।
Same auth model, same idempotency contract, same error envelope. The difference is that Verify generates the code, picks the channel, and runs the rate limits, so you don't.
Verify
एक call code भेजती है; एक call उसे recipient के आधार पर check करती है। Code, session और limits हमारे जिम्मे हैं।
await bird.verify.verifications.create({
to: { phone_number: "+15551234567" },
});SMS
Raw send, जब आप code generation और retry policy खुद संभालना चाहते हैं।
await bird.sms.send({
from: "Bird",
to: "+15551234567",
text: `Your code is ${code}.`,
category: "authentication",
});वह sender जो आपके users को दिखता है: Authifly
आपके end users को उनके codes Authifly से मिलते हैं, जो Bird की verification brand है। साझा senders पर OTP email otp@verify.authifly.com से आता है और SMS संदेश में Authifly का नाम होता है, ताकि codes एक सुसंगत पहचान के तहत आएं जिसे चलाना आपको नहीं पड़ता। यदि किसी recipient को अप्रत्याशित code मिलता है, तो authifly.com उन्हें आश्वस्त करता है कि Authifly किसी व्यवसाय की ओर से वैध one-time codes भेजती है। Authifly का संचालन Bird B.V. करती है।
authifly.com पर जाएंआपके बाकी messaging जैसी ही platform पर verification।
Start a build today, or talk to us about the channels, volume, and pricing you need.