---
title: "Retrieve recipient account requirements dynamically"
method: GET
path: "/v1/quotes/{quoteId}/account-requirements"
tags: ["recipient"]
---

# Retrieve recipient account requirements dynamically

`GET /v1/quotes/{quoteId}/account-requirements`

{% 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`<br>
`POST /v1/quotes/{quoteId}/account-requirements`<br>
`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](/guides/product/kyc/partner-accounts) 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 %}

## Path parameters

- `quoteId` string, required

## Query parameters

- `originatorLegalEntityType` 'BUSINESS' | 'PRIVATE'
- `addressRequired` boolean

## Headers

- `Accept-Minor-Version` 1
- `X-External-Correlation-Id` string, uuid

## Response `200`

Dynamic account requirements for building a recipient form.

- object[] — Dynamic account-requirements response used to build recipient forms. The structure and the fields returned vary by currency, recipient type, route, and sometimes previously provided inputs. Treat this as a schema for a dynamically generated form definition rather than a fixed set of recipient fields.
  - `type` string — Requirement group identifier (route/payout-method specific).
  - `title` string — Human-readable title for the requirement group.
  - `usageInfo` string — Optional usage/help text.
  - `fields` object[] — List of UI field groups to collect required data.
    - `name` string — Display name of this group.
    - `group` object[] — The actual fields within this group.
      - `key` string — Key to include in JSON when submitting recipient details.
      - `name` string — Human-readable label.
      - `type` string — UI field type.
      - `refreshRequirementsOnChange` boolean — If true, changing this field can alter requirements; call the POST account-requirements endpoint with updated data to refresh requirements.
      - `required` boolean — Indicates whether this field is mandatory.
      - `displayFormat` string — Optional display formatting hint.
      - `example` string — Example value for the field (may be empty string).
      - `minLength` integer — Minimum allowed length, when applicable.
      - `maxLength` integer — Maximum allowed length, when applicable.
      - `validationRegexp` string — Regex pattern for validation, when applicable.
      - `validationAsync` string — Deprecated. This validation will instead be performed when submitting the request.
      - `valuesAllowed` object[], nullable — Allowed values for select/radio inputs; null for free-text/date inputs.
        - `key` string — Machine-readable value.
        - `name` string — Human-readable value label.

## Other responses

- `401` — Unauthorized.
- `403` — Forbidden.
- `404` — Not Found.
- `429` — Rate limit exceeded. Retry after the number of seconds specified in the `Retry-After` header.

---

[API](https://skmtc.net/wise/apis/platform-api.md) · [All operations](https://skmtc.net/wise/apis/platform-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/wise/platform-api/revisions/4907a1d269ab/schema)