OTP Verification
OTP Verification signs an Authorization with a one-time code. It's the second half of a two-step consent process: first, Opt-In presents terms and creates the Authorization when the customer accepts; then OTP Verification sends a code and, when entered correctly, applies the customer's signature to that Authorization.
The distinction matters. This node doesn't verify that a phone number belongs to someone — that's what POC Verification does. OTP Verification proves identity for the purpose of signing a specific authorization record. The output is a signed Authorization in the Authorizations API, not a verified contact.
The Two-Step Pattern
Opt-In and OTP Verification work as a pair. Opt-In displays consent terms and creates an Authorization when the customer taps "Accept". It stores the authorization ID in a variable. OTP Verification then references that variable, sends a code to the customer, and marks the Authorization as signed when they enter it correctly.
The authorization ID variable is the link between them. Whatever variable name Opt-In uses to store the authorization ID, OTP Verification must reference the same variable.
Contact Source Options
The node needs to know where to send the code. Five options are available.
WhatsApp number uses the phone number the customer is currently messaging from. This is the most common choice — the customer is already in this conversation, so they'll receive the code here or via SMS to the same number.
Stored phone POC looks up the borrower's phone Point of Contact record. This requires the borrower to have a phone POC already created, typically via Create Entity earlier in the flow.
Stored email POC does the same for email contacts.
Variable pulls the contact value from a flow variable. Useful when you've collected a phone number or email through Ask Phone or Ask Email but haven't yet created a POC record.
Manual uses a hardcoded value. Rare in production, but useful for testing.
Delivery Channel
Separate from where the contact comes from, you choose how to deliver the code: SMS, WhatsApp, or email. A common pattern sends to the WhatsApp number but delivers via SMS — the customer gets a text message to the same phone they're chatting on.
The templateId specifies which message template to use for delivering the code. This template must exist in your system's configuration.
Backup Methods
When enabled, backup methods provide fallback delivery if the primary channel fails or the customer reports not receiving the code. Configure a list of alternative contact sources and channels. If the customer clicks "I didn't receive it", the system tries the next method in the list.
A typical setup: primary delivery via SMS to the WhatsApp number, backup delivery via WhatsApp message to the same number. Different channel, same destination — sometimes one gets through when the other doesn't.
Configuration
| Option | Description |
|---|---|
| Authorization ID Variable | Variable containing the authorization ID from Opt-In |
| Contact Source | Where to get the contact: WhatsApp number, stored POC, variable, or manual |
| Template Channel | How to deliver the code: SMS, WhatsApp, or email |
templateId | Message template for the OTP delivery |
retryTimeoutSeconds | Seconds before resend is allowed (default: 60) |
expirationTimeoutSeconds | How long the code remains valid (default: 60) |
| Max Attempts | Wrong code attempts before routing to timeout (default: 3) |
| Enable Backup Methods | Whether to offer fallback delivery options |
Output Handles
| Handle | When |
|---|---|
| Continue | Code verified, authorization signed |
| Timeout/Max Attempts | Too many wrong codes or code expired |
| Error | Authorization not found, template missing, system failure |
OTP Verification vs POC Verification
Both nodes send codes and wait for responses. The difference is what they're verifying.
OTP Verification signs an Authorization. It requires an authorization ID from a previous Opt-In node, and when successful, that Authorization record gets marked as signed. The contact used is incidental — it's just the delivery mechanism.
POC Verification confirms contact ownership. It requires a stored Point of Contact record and, when successful, marks that POC's isVerified field as true. There's no authorization involved.
If you need documented consent with a signature trail, use the Opt-In → OTP Verification pattern. If you just need to confirm a phone number or email belongs to the customer, use POC Verification.
Prerequisites
The authorization must already exist. This means an Opt-In node must have executed earlier in the conversation, the customer must have accepted the terms, and the authorization ID must be stored in the variable you reference. If any of these conditions aren't met, the node routes to the error handle.
For stored POC contact sources, the borrower must have a matching Point of Contact record. For variable sources, the referenced variable must contain a valid phone number or email.
Things to Know
The customer flow is interactive. The node first shows a message saying a code was sent, with two buttons: "I have the code" and "I didn't receive it". Only after clicking the first button does the customer get prompted to enter the code. This gives them time to check their messages.
Retry timing matters. The retryTimeoutSeconds controls how long before a resend is allowed. Setting this too low risks duplicate codes causing confusion; too high and frustrated customers give up.
Expiration and max attempts both route to the same handle. Whether the code expired or the customer entered wrong codes too many times, the result is the same: the timeout/max attempts output. Design your flow to handle both cases — typically a message explaining what happened and an option to restart the process.