User Input

Some connections need data from you before the provider can start: a lookup key that selects the person (a registration id, a phone number, a national id number), or the values a match connection should compare. You send these in the single userInput object of Create Verification.

Where the schema comes from

Every connection publishes its requirements as userInputSchema in Get Connections. The Console shows the same fields on a connection’s detail sheet under Data → Request Params. Illustrative schema (read the actual fields from your connection):

{
  "userInputSchema": {
    "fields": {
      "registrationId": {
        "required": true,
        "hint": "Smart-ID registrationId must be at least 8 characters"
      },
      "country": {
        "type": "select",
        "required": true,
        "enum": [
          "EE",
          "LV",
          "LT"
        ]
      }
    }
  }
}

A connection with no userInputSchema needs no input. The user selects themselves in the provider’s own UI (most redirect-based eIDs work this way).

Field rules

Rule	Meaning
`type`	The kind of input: `text`, `password`, `image` (base64-encoded image), `select`, or `date` (`YYYY-MM-DD`). Omitted for plain text fields.
`required`	Validated before the session starts. A missing or empty required field returns `400 VALIDATION_INVALID_PARAMETER` naming the field.
`enum`	Allowed values for a `select` field. Any other value returns `400`.
`optionsUrl`	For `select` fields whose options come from the provider at runtime (for example a bank list). Fetch the options from that URL and let the user choose.
`pattern`	A regular expression describing the expected format. Shown as guidance. Validate it client-side.
`hint`	Human-readable help text for your form.

Keys the connection’s userInputSchema does not declare are dropped before the provider is called. Only a connection without a userInputSchema receives userInput unchanged. A value the connection or its provider rejects (for example a malformed national ID number) returns 422 VALIDATION_INVALID_USER_DATA. Record-level rules that a schema cannot express (for example “provide one of email, phone, or identification number”) are enforced by the provider and surface as a failed session.

One field, two purposes

userInput is one flat map. Hopae decides what each value is for based on the connection’s credential.verificationModel:

disclosure: the values select the person or authorise the lookup. The provider then discloses the person’s attributes.
match: the same values are also the claims to compare. The provider answers whether they match, field by field, under match in the userinfo response. See Verification Model.

You never need to split the map into lookup keys and comparison values yourself.

Examples

{
  "connectionId": "smart-id",
  "userInput": {
    "registrationId": "PNOEE-38001085718"
  }
}

{
  "connectionId": "br-cpf-cnh-match",
  "userInput": {
    "cpf": "12345678900",
    "name": "Manuela Elisa da Mota",
    "birthdate": "1975-06-04",
    "picture": "/9j/4AAQSkZJRgABAQAAAQABAAD..."
  }
}

{
  "connectionId": "idin-full-identification",
  "userInput": {
    "presetBank": "INGBNL2A"
  }
}

Keys are the OIDC-normalized names listed in the schema (for example name, birthdate). They are echoed back unchanged in match.submitted_fields and match.details. The provenance block keeps the provider’s native names so the audit trail stays aligned with the source.

Overview

OIDC

Verifications

Where the schema comes from

Field rules

One field, two purposes

Examples

​Where the schema comes from

​Field rules

​One field, two purposes

​Examples

Where the schema comes from

Field rules

One field, two purposes

Examples