The SMS verification API
If you'd rather wire verification into your own backend than drop in a widget, it's two calls: start a verification, then check the code. Here's exactly how it works, what comes back, and the details that matter.
Start, then check
POST a phone number to start a verification and you get an id. The code goes out over iMessage or SMS automatically. When the user types it in, POST the id and code to confirm:
The rules that matter
Codes are single-use, expire in a few minutes, and lock out after too many wrong attempts. The response tells you the channel it was delivered on (imessage or sms). Every successful verification is logged as an exportable proof-of-consent record.
Auth and keys
Authenticate with a Bearer API key from your dashboard. Full reference and an OpenAPI spec live in the docs — agent-friendly, so a customer's AI can wire it up too.
# start
curl https://ibluetext.com/api/v1/verify \
-H "Authorization: Bearer $IBT_KEY" -H "Content-Type: application/json" \
-d '{"phone":"+18135550142"}'
# -> { "id": 5512, "status": "queued" }
# check
curl "https://ibluetext.com/api/v1/verify?action=check" \
-H "Authorization: Bearer $IBT_KEY" -H "Content-Type: application/json" \
-d '{"id":5512,"code":"481920"}'
# -> { "verified": true, "channel": "imessage" }Get a free API key → Read the docs
Related
Frequently asked questions
Is there a free tier for the SMS verification API?
Yes — your first 10 verifications are free (plus 100 free lookups), no credit card, so you can build and test before paying. After that it's a flat ½¢ each.
What does the API return?
On start, a verification id. On check, whether it verified and which channel (iMessage or SMS) delivered the code.
How are codes secured?
Single-use, short expiry, hashed server-side, and rate-limited attempts.