User data and friction

The trade-off

When you create a magic link, you choose how much end-user data to send up front. More data means less typing in the widget — and usually higher conversion.

Approach	Partner effort	User friction	When to use
Full prefills	High	Lowest	You already have KYC + payout data
Partial + webhook	Medium	Low	You have some fields; fetch the rest async
Minimal (`referenceId` only)	Low	Highest	POC, or flows that collect everything in-widget

Prefills and user.data_request matter most for m2m and request-style configs. Flows like smart and send are designed for minimal create payloads — users complete corridor and payment details in the widget. See M2M flow.

What “friction” means

Friction is every step the user must complete before they can confirm a transfer:

Low friction

You prefilled name, ID, DOB, and payout method. The user reviews and confirms.

Medium friction

Some fields are prefilled. Missing CIP fields may trigger a data request webhook or a short form.

High friction

Only referenceId is known. The user enters identity and payment data in the widget and completes CIP.

Prefill shape (`config.userData`)

Typical CIP-related fields (flow-dependent):

Field	Impact if missing
`name.firstName` / `lastName` / …	User types legal name
`idNumber` / `idType`	User enters ID; may need document capture
`dob`	User picks date of birth
`paymentMethod`	User adds bank/card (when the flow supports partner payout)

Example (m2m):

curl -X POST https://raas-widgets-backend-sandbox.up.railway.app/partner/links \
  -H "X-API-Key: raas_sandbox_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "referenceId": "user_12345",
    "flow": "m2m",
    "config": {
      "userData": {
        "name": {
          "firstName": "Juan",
          "lastName": "Garcia"
        },
        "dob": "1990-05-15"
      }
    }
  }'

Progressive enhancement

Start thin, then add data as your systems allow:

MVP

Mint links with referenceId only (or use smart). Accept higher friction while you ship.

Add profile fields

Pass name (and DOB/ID when available) in config.userData for m2m/request.

Handle data requests

Implement user.data_request so you can fill gaps without blocking the user. See Data requests.

Full prefills

Send complete CIP + payment method when you have trusted KYC data.

Precedence

When the same field arrives from multiple sources, RaaS Widgets keeps the highest-priority value:

Partner API (link create)
Partner webhook (PUT /partner/data-requests/:id)
Widget (user input)

Higher-priority data is not overwritten by lower-priority sources. Prefill what you trust; let webhooks and the widget fill gaps.

Getting Started

Request API

Concepts

Integration

Flows

Webhooks

Operations

The trade-off

What “friction” means

Prefill shape (`config.userData`)

Progressive enhancement

Precedence

Next steps

Data requests

M2M flow

​The trade-off

​What “friction” means

​Prefill shape (config.userData)

​Progressive enhancement

​Precedence

​Next steps

Data requests

M2M flow

The trade-off

What “friction” means

Prefill shape (`config.userData`)

Progressive enhancement

Precedence

Next steps