These docs are for v3. Click to read the latest docs for v4.

🚧

Users is in Beta

To enable users on your Wyre account please contact [email protected]

The Users API is a simple, versatile KYC system used for controlling access to the Wyre platform network. It combines requirements and user data into a single view making it easy for you to understand the next steps for a particular user across a variety of usecases and workflows.

📘

Contents:

  1. Definitions
  2. Overview
  3. Scopes
  4. User Statuses
  5. Fields
  6. Field IDs
  7. Field Types
  8. Integration Types

Definitions

  • User: the end-user originating the request
  • Partner: You, the Wyre integrator!
  • Field: A bucket for a specific piece of user data
  • Scope: A specific segment of functionality on the Wyre platform

Overview

The basic process looks like this:

  1. Create User
  2. Get Approved
  3. Transfer!

Step 1: Creating the User

Call the create user API endpoint to create the user. This call will return a set of fields contextualized by the scopes parameter provided. User creation also may include blockchain address generation if desired.

Step 2: Get Approved

After the user is created, all user API calls require you to use masquerading on your requests. This simple pattern helps to firewall permission boundaries between users and your partner-level API credentials.

Approvals in the users system exist only in the context of scopes. The specific user requirements enforced for a given scope are determined by your partner agreement with Wyre. Because end-user requirements differ across available Wyre functionality, scopes are used to constrain the API based on the specific intent of a single user.

Broadly, to achieve user approval:

  1. Filter the fields returned by either create user or get user endpoints for those which are OPEN
  2. Collect data for one or more of these open fields to your end user
  3. Submit this data to Wyre
  4. Repeat

When there are no longer any OPEN fields, the end user is done with their turn. Our system is diligently processing their information. After this stage:

  • the user status may transition to APPROVED
  • or the user status may transition to CLOSED if fraud/compliance problems have been detected. Wyre customer support followup is required
  • or the user status may transition back to OPEN if correctable problems were detected

Step 3: Transfer!

Now that your user is approved, you may use the transfer API on their behalf! Remember to use masquerading for requests made on behalf of your users.

Users each have their own set of custodialized balances (including all our supported fiat and crypto). This is where funds are reflected which is sent to the blockchain addresses tied to the user. Users may be used as the source or destination via the transfer API to move and exchange these funds.

658

Scopes

A scope is an identifier for a specific segment of functionality within the Wyre platform. In some contexts, multiple scopes can apply.

ScopeMeaning
TRANSFERApproved transfer scope is required for access to the Swaps API.
ACHApproved ACH scope is required to activate ACH direct debits for users.
DEBIT_CARD_L2Approved L2 scope is required for higher limit card purchases.
*Note, Wyre always by default supports credit cards as well.

User Statuses

Users can have one of 4 statuses. These apply only within the context of a set of scopes.

StatusDescription
OPENWaiting on data to be submitted to one or more fields.

This is the initial state before any information has been submitted, or if there were correctable problems with a previous submission.
PENDINGInformation has been fully submitted and is waiting on review from Wyre.
APPROVEDInformation has been reviewed and accepted by Wyre
CLOSEDThe Account has been closed and may not transact. Customer service followup is necessary for further actions.

Fields

All fields present on a User object are required in context of the currently specified scope(s). Each field has the following parameters:

Field ParameterDescription
valueA representation of the underlying KYC data. Actual format depends on the type of field
errorA message indicating the nature of a correctable problem. Accompanied by an OPEN status.
statusOne of:

OPEN: The field is awaiting user data. This is the initial state before any information has been submitted, or if there were correctable problems with a previous submission.

SUBMITTED: The field value has been uploaded and accepted.

Field IDs

The field IDs required for your integration depend on the scopes you want to support.

fieldId ValueField TypeDescriptionScope Required
firstNameSTRINGFirst name of the end userTransfer, ACH
lastNameSTRINGLast name of the end userTransfer, ACH, DEBIT_CARD_L2
cellphoneNumberCELLPHONEthe cellphone number of the account holderACH, DEBIT_CARD_L2
emailEMAILthe email address of the account holderACH, DEBIT_CARD_L2
residenceAddressADDRESSthe residence address of the account holderTransfer, ACH, DEBIT_CARD_L2
dateOfBirthDATEthe date of birth of the person, e.g. 1990-01-01Transfer, ACH, DEBIT_CARD_L2

Field Types

The field type is hard-coded to each field ID and determines the JSON format and upfront validation rules on it.

fieldType valueDescription
STRING
CELLPHONEA full cellphone number including country code

e.g. +15554445555
EMAILA correctly formatted email address
ADDRESSAn address object. Address format is:

json { "street1": "1 Market St", "street2": "Suite 402", "city": "San Francisco", "state": "CA", "postalCode": "94105", "country": "US" }
DATESpecifies a particular day. Format is YYYY-MM-DD,

e.g. 1992-12-15