message.comDevelopers
Developers/Verify/Setup times

Verify channel setup times

The VerifyChannel type is stable across all seven channels today, but not every channel dispatches on every workspace immediately. Setup time is a carrier-registration and review constraint, not a code difference: the request and response shapes are identical whether a channel is live or not (full field list in the Verify API reference).

Setup time by channel

ChannelSetup timePrerequisitesAvailability today
sms5 minutesActivate Verify. No carrier registration blocks the default template variants.Available. Sends dispatch immediately.
email5 minutesActivate Verify. No domain setup required; codes send from our shared sending domain.Available. Sends dispatch immediately.
voice1 hourActivate Verify. Voice OTP delivery runs on our own callout stack, provisioned per workspace.Disabled for sending today. POST /v1/verify with channel: "voice" returns 422 channel_not_available.
totp1 hourActivate Verify. TOTP verifies a code the user's own authenticator app already generates, so setup is enrollment logic on your side, not carrier registration on ours.Disabled for sending today. POST /v1/verify with channel: "totp" returns 422 channel_not_available.
push1 dayActivate Verify. Requires registering your app's push credentials (APNs / FCM) with your Verify Service.Disabled for sending today. POST /v1/verify with channel: "push" returns 422 channel_not_available.
whatsapp2-4 weeksActivate Verify. Requires a Meta Business Manager verification and an approved WhatsApp message template, both gated by Meta's own review timeline.Disabled for sending today. POST /v1/verify with channel: "whatsapp" returns 422 channel_not_available.
sna (Silent Network Auth)2-4 weeksActivate Verify. Requires direct carrier and mobile-network-operator integration to authenticate a SIM without sending a code at all.Disabled for sending today. POST /v1/verify with channel: "sna" returns 422 channel_not_available.

Why setup time varies

SMS and email dispatch through infrastructure message.com already owns and operates, so there is no external approval step between activating Verify and a code going out. The remaining five channels each depend on a third party's review process before message.com is allowed to send through them on a customer's behalf:

  • Voice and TOTP sit at 1 hour because they run on infrastructure we control (an internal callout worker for voice, standard TOTP verification for authenticator apps) but still need a short per-workspace provisioning step before general availability.
  • Pushsits at 1 day because it needs your app's own push credentials registered against your Verify Service before a notification can be delivered.
  • WhatsApp and Silent Network Authsit at 2-4 weeks because both depend on external review cycles outside message.com's control: Meta's WhatsApp Business template approval, and direct integration agreements with mobile network operators for SNA.

What happens when you call a disabled channel

Calling POST /v1/verify with a channel that is not yet live for your workspace returns a 422 with a machine-readable reason, never a fake success. The channel name you sent is echoed back so your error handling can branch on it directly.

422 Unprocessable
{
  "error": "channel_not_available",
  "channel": "whatsapp"
}

This check happens before country allowlists, velocity caps, or billing are evaluated, so a disabled-channel call never touches your credit balance. The full guard order and every other machine reason are in the dedicated Verify API error codes reference.

Sending an unrecognized channel string (something outside email, sms, voice, whatsapp, push, totp, sna) fails earlier with a 400 validation_error, before it ever reaches the channel-availability check.channel_not_available only fires for a channel that is a real, typed member of the VerifyChannel union but is not dispatching yet.

Next steps