Every failed request returns a JSON body with success: false. Branch on
error_code rather than on message: the code is stable, the message is not.
Error response
{ "success": false, "message": "There are insufficient funds in the wallet", "error_code": "transaction-insufficient-funds"}
Field
Description
success
Always false on an error response.
message
Human-readable description. Subject to change; do not parse it.
error_code
Stable machine-readable code. Absent on some authorization failures and on schema validation errors.
errors
Structured validation details, when available.
Treat an absent error_code as a generic failure of that HTTP status rather
than as a distinct condition. Always handle the status code as well as the
code.
Returned when Dots cannot deliver a verification code. These surface on
Send a Verification Token. A
white-labeled integration has to handle them directly, because your UI — not a
Dots-hosted Flow — owns the phone number the user typed in.
Code
Status
Description
phone-number-invalid
422
The phone number is not a valid destination. Re-collect the number.
phone-number-not-sms-capable
422
The number cannot receive SMS, typically a landline. Ask for a mobile number.
phone-number-unsubscribed
422
The number opted out of Dots messages. The user must use a different number or contact support.
phone-number-temporarily-blocked
422
The carrier is temporarily blocking the number. Retry later or use a different number.
verification-max-attempts
429
Too many verification attempts for this number. Wait before retrying.
phone-number-calls-not-supported
422
The number cannot receive a voice call. Retry without use_voice.
phone-number-call-blocked
422
The voice call was blocked. Retry without use_voice.
phone-number-invalid, phone-number-not-sms-capable, and
phone-number-unsubscribed will not succeed on retry with the same number —
prompt the user for a different one. phone-number-temporarily-blocked and
verification-max-attempts are time-based and are worth retrying with
backoff.