Opt-In

Opt-In presents consent terms to the customer and creates an Authorization record when they accept. The node sends a message with an accept button — a single tap creates a formal record of consent in the Authorizations API, linked to the customer's identity and the specific policy they agreed to.

This is the first half of a two-step consent process. Opt-In collects agreement and creates the Authorization; OTP Verification can then sign it with a one-time code for stronger proof of identity. Many flows use both steps together, though Opt-In can also stand alone when a button tap is sufficient.

How It Works

The node sends a WhatsApp message containing the consent text and a single button. When the customer taps the button, three things happen: an Authorization record is created in the system (linked to the policy, the borrower, and their identity), the authorization ID is stored in a conversation variable, and the flow advances to the next node.

The consent message can come from two places. If use policy short text is enabled, the node pulls the text directly from the policy definition in the data model — keeping consent language consistent with your legal team's wording. Otherwise, you write custom messages in the node configuration.

When to Use It

Any operation that requires documented consent is a good candidate. Some common examples:

Before biometric verification. Liveness checks require documented consent. Place an Opt-In node before Liveness Verification to authorize the processing of biometric data.

Credit bureau authorization. Querying a credit bureau requires the customer's explicit consent. Opt-In creates the authorization record that proves it was given.

Regulatory compliance. Terms acceptance, data processing agreements, privacy policies — any of these can be gated by an Opt-In node.

A Common Pattern: Check Before Asking

A returning customer shouldn't re-authorize something they already agreed to. Use Read Authorization first to check whether the authorization already exists. If it does, skip the consent flow entirely.

This avoids redundant prompts and keeps the conversation moving for customers who have already given consent.

Opt-In Before Knowing the Customer

Opt-In can be the first node of the flow, before anyone is identified. On WhatsApp and web the acceptance is saved as an authorization with no customer, signed with the channel address (the phone number on WhatsApp, the browser session on web) and tied to the conversation. No customer is created for it.

The recommended order:

1. Opt-In, with Identity Key empty.
2. The questions the flow needs, saved in conversation variables.
3. Login, or Create Borrower with Authenticate Conversation on.

When step 3 identifies the customer, the authorization is attached to them automatically, and that node leaves an info notice, Authorization linked to customer. Identifying the customer by hand with Identify Client from the chat attaches it too. From then on it is an ordinary authorization of the customer, and Read Authorization finds it.

A few conditions decide whether that happens:

• Same conversation. A new device, a private window or a restarted session starts a new conversation, and the acceptance stays in the old one.
• Create Borrower only when it creates. Authenticate Conversation is off by default, and it only authenticates when the node creates the customer. If Find before creating finds one that already exists, nothing is attached, on purpose: a tax ID is public. Identify existing customers with Login and OTP.
• No identification, no attachment. If the conversation ends without identifying the customer, the authorization stays without one. No placeholder customer is created.
• Leave Identity Key empty. With an identity configured and no customer yet, every acceptance leaves a warning notice saying it was signed with the channel address instead of that identity.
• Older consents. Acceptances from before October 14, 2026 were not tied to their conversation and stay unattached. Read Authorization by Authorization ID with Link to a customer attaches them by hand.

Configuration

The identity key determines which of the customer's identity documents gets linked to the authorization. In a flow that branches by customer type, an individual path might use person_id (cedula) while a business path uses tax_id (RUC). If no identity key is configured, or the customer has no value for it yet, the authorization is signed with the channel address instead: the phone number on WhatsApp, the browser session on web.

Output Handles

Things to Know

The node waits for the customer to respond. Unlike Message, which sends and immediately continues, Opt-In pauses the flow until the customer taps the accept button. The conversation stays on this node until that happens.

WhatsApp and web. On those two channels the acceptance creates the authorization. An Opt-In answered by email creates none. The 20-character limit on button labels is a WhatsApp platform constraint.

An identity key needs the identity first. If the identity key is set to person_id but there is no customer yet, or the customer has no value for that identity, the acceptance is not lost: it is signed with the channel address and the node leaves a warning notice. To sign with the identity, collect it — via Login, Create Borrower, or Customer Update — before this node runs.

The policy must exist in the data model. Referencing a nonexistent policy key routes to the error handle. Verify the key matches what's configured in the tenant's data model.