> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hopae.com/llms.txt
> Use this file to discover all available pages before exploring further.

# User Input

> How to fill the userInput field when you create a verification. The schema comes from the connection, not from a fixed list of providers.

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](/v2/api-reference/verifications/create-verification).

## Where the schema comes from

Every connection publishes its requirements as `userInputSchema` in [Get Connections](/v2/api-reference/verifications/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):

```json theme={null}
{
  "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](/v2/guides/concepts/verification-model).

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

## Examples

<CodeGroup>
  ```json Smart-ID (disclosure) theme={null}
  {
    "connectionId": "smart-id",
    "userInput": {
      "registrationId": "PNOEE-38001085718"
    }
  }
  ```

  ```json Brazil CNH (match) theme={null}
  {
    "connectionId": "br-cpf-cnh-match",
    "userInput": {
      "cpf": "12345678900",
      "name": "Manuela Elisa da Mota",
      "birthdate": "1975-06-04",
      "picture": "/9j/4AAQSkZJRgABAQAAAQABAAD..."
    }
  }
  ```

  ```json iDIN (select with runtime options) theme={null}
  {
    "connectionId": "idin-full-identification",
    "userInput": {
      "presetBank": "INGBNL2A"
    }
  }
  ```
</CodeGroup>

<Note>
  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.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.