Send verification codes with abuse protection

OTP Abuse Protection applies to phone verification sends through SMS, WhatsApp, and Smart routing. Use purpose: "otp" to identify the request consistently, including verification content written in another language.

Use one recipient, one code, and one logical request key. A saved authentication template can supply the body; pass the caller-facing OTP variable shown by Convert. New codes or changed recipient/payload values require new idempotency keys.

1234567{
  "to": "+2348012345678",
  "channel": "smart",
  "purpose": "otp",
  "message": "Your sign-in code is 638492. Do not share it.",
  "test": true
}

The displayed example validates only. Use real authorised recipients and remove the test flag for intended delivery. A controlled live check is needed to verify provider acceptance and receipts.

OTP controls can return 429 with an otp_* error code and retry delay where available. Inspect the reason, respect the delay, and avoid automatically issuing many new requests while blocked.

Convert's controls complement your own authentication security. Your application still needs code expiry, verification-attempt limits, secure generation, account-enumeration defenses, and protection around the user-facing request action.

Retry the same uncertain send with the original key and payload. Generating a fresh key after a timeout creates another logical send and can duplicate a code notification that the provider already accepted.

Do not persist OTPs as contact profile fields. The messaging API's template variables are not automatically copied into persistent custom fields. Keep verification state in your application's appropriate secure store.

Next: read templates, idempotency, and errors.