# Retrieve recipient account requirements dynamically

{% admonition type="info" %}
Please note that to use v1.1 Accept-Minor-Version: 1 request header must be set.
{% /admonition %}

GET /v1/quotes/{quoteId}/account-requirements
POST /v1/quotes/{quoteId}/account-requirements
GET /v1/account-requirements?source=EUR&target=USD&sourceAmount=1000

You can use the data returned by this API to build a dynamic user interface for recipient creation. The GET and POST account-requirements endpoints help you to figure out which fields are required to create a valid recipient for different currencies. This is a step-by-step guide on how these endpoints work.

Use the GET endpoint to learn what datapoints are required to send a payment to your beneficiary. As you build that form, use the POST endpoint to learn if any additional datapoints are required as a result of passing a field that has "refreshRequirementsOnChange": true in the GET response. You should be posting the same recipient account payload that will be posted to /v1/accounts.

An example of this would be address.country. Some countries, like the United States, have a lower level organization, "state" or "territory". After POSTing the recipient payload with address.country = "US", the list of possible states will appear in the response.

The third endpoint above is used to get account requirements for a specific currency route and amount without referring to a quote but with the amount, source and target currencies passed as URL parameters. Generally this approach is not recommended, you should have your user create a quote resource first and use this to generate the recipient account requirements. This is because some payout methods will only surface when the profile-context is known, for example (at the time of this writing), Business Payments to Chinese Yuan use a different payout method than what is revealed by GET /v1/account-requirements?source=USD&target=CNY&sourceAmount=1000.

All new integrations should use the v1.1 of GET and POST account requirements, enabled using the Accept-Minor-Version header. It enables you to fetch the requirements including both the recipient name and email fields in the dynamic form, simplifying implementation of the form. Name and email address dynamic fields are required to support currencies such as KRW, JPY and RUB, and also remove the need for manual name validation.

These endpoints allow use of both v1 and v2 quotes using long or UUID based IDs, supporting legacy implementations using v1 quotes.

These endpoints accept an optional query parameter originatorLegalEntityType. When the transfer is initiated by a Third Party Partner we are not aware whether the actual sender is a business or person. In such cases, this parameter should be passed to receive correct requirements. The legal entity type should be one of the following values: BUSINESS, PRIVATE. This parameter is optional and the default value is the type of the partner profile.

#### Collecting Recipient Address

Normally our account requirements will instruct when a recipient address is required. However, in some situations it's desirable to force the requirement so that an address can be provided to Wise. To do this, add the query parameter ?addressRequired=true to your request and address will always be returned as a required field.

{% admonition type="warning" %}
Address requirement fields are subject to change. Your integration should be built in a way to handle unrecognized or changed fields.
{% /admonition %}

Endpoint: GET /v1/quotes/{quoteId}/account-requirements
Security: UserToken

## Path parameters:

  - `quoteId` (string, required)
    Quote ID (supports long or UUID based IDs).

## Query parameters:

  - `originatorLegalEntityType` (string)
    Legal entity type override for the actual sender.
    Enum: "BUSINESS", "PRIVATE"

  - `addressRequired` (boolean)
    Set to true so address is always required.

## Header parameters:

  - `Accept-Minor-Version` (integer)
    Set to 1 to enable v1.1.
    Enum: 1

## Response 200 fields (application/json):

  - `type` (string)
    Requirement group identifier (route/payout-method specific).
    Example: "south_korean_paygate"

  - `title` (string)
    Human-readable title for the requirement group.
    Example: "PayGate"

  - `usageInfo` (string)
    Optional usage/help text.

  - `fields` (array)
    List of UI field groups to collect required data.

  - `fields.name` (string)
    Display name of this group.
    Example: "E-mail"

  - `fields.group` (array)
    The actual fields within this group.

  - `fields.group.key` (string)
    Key to include in JSON when submitting recipient details.
    Example: "email"

  - `fields.group.name` (string)
    Human-readable label.
    Example: "E-mail"

  - `fields.group.type` (string)
    UI field type.
    Example: "text"

  - `fields.group.refreshRequirementsOnChange` (boolean)
    If true, changing this field can alter requirements; call the POST account-requirements endpoint with updated data to refresh requirements.

  - `fields.group.required` (boolean)
    Indicates whether this field is mandatory.
    Example: true

  - `fields.group.displayFormat` (string)
    Optional display formatting hint.

  - `fields.group.example` (string)
    Example value for the field (may be empty string).
    Example: "example@example.ex"

  - `fields.group.minLength` (integer)
    Minimum allowed length, when applicable.

  - `fields.group.maxLength` (integer)
    Maximum allowed length, when applicable.

  - `fields.group.validationRegexp` (string)
    Regex pattern for validation, when applicable.
    Example: "^[^\\s]+@[^\\s]+\\.[^\\s]{2,}$"

  - `fields.group.valuesAllowed` (array,null)
    Allowed values for select/radio inputs; null for free-text/date inputs.

  - `fields.group.valuesAllowed.key` (string)
    Machine-readable value.
    Example: "PRIVATE"

  - `fields.group.valuesAllowed.name` (string)
    Human-readable value label.
    Example: "Person"

  - `fields.group.validationAsync` (string)
    Deprecated. This validation will instead be performed when submitting the request.


## Response 401 fields

## Response 403 fields

## Response 404 fields