Endpoints
POST /1-click
Begin a 1-Click Signup flow
Method | POST |
---|---|
Path | /1-click |
Request
Full Definition
We recommend looking at the partial definitions below under the integration type tabs (Hosted, Semi-Hosted, and Non-Hosted) because they show only the properties relevant to the integration type you choose. The full definition here shows all possible properties, but some may not be relevant to your integration type.
{
phone: string,
email?: string,
birthDate?: string,
credentialRequests?: CredentialRequest[],
content?: {
title?: "Signup" | "Login" | "Verify" | "Apply",
description?: string
}
redirectUrl?: string
}
Property | Required? | Type | Format | Default | Description | Example |
---|---|---|---|---|---|---|
phone | required | string | E.164 | none | User's phone number (in E.164 format) | "+10123456789" |
email | optional | string | none | User's email address | "richard@piedpiper.net" | |
birthDate | optional | string | YYYY-MM-DD | none | User's birth date (in Sandbox, this must be "1989-08-01" to pass validation) | "1989-08-01" |
credentialRequests | optional | CredentialRequest[] | See CredentialRequest | Defined by the default credential requests brand setting in your Dashboard | List of CredentialRequest objects (which encode which credentials you're asking for) | See CredentialRequest example |
content.title | optional | enum | Title Case | "Signup" | What word should be displayed after "1-Click" (accepted values are Signup , Login , Verify , and Apply ) | "Verify" |
content.description | optional | string | Sentence case | none | What text should be displayed under the 1-Click page title | "Confirm your new Hooli account info:" |
redirectUrl | optional | string | URL | defined for your brand in the Dashboard | Overrides the default redirect URL in your brand settings | "https://hooli.com/verifiedAlternate" |
- Hosted
- Semi-Hosted
- Non-Hosted
With the Hosted tab active above, your brand's integration type setting should be set to Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
{
phone: string,
email?: string,
birthDate?: string,
credentialRequests?: CredentialRequest[],
content?: {
title?: "Signup" | "Login" | "Verify" | "Apply",
description?: string
}
redirectUrl?: string
}
Property | Required? | Type | Format | Default | Description | Example |
---|---|---|---|---|---|---|
phone | required | string | E.164 | none | User's phone number (in E.164 format) | "+10123456789" |
email | optional | string | none | User's email address | "richard@piedpiper.net" | |
birthDate | optional | string | YYYY-MM-DD | none | User's birth date (in Sandbox, this must be "1989-08-01" to pass validation) | "1989-08-01" |
credentialRequests | optional | CredentialRequest[] | See CredentialRequest | Defined by the default credential requests brand setting in your Dashboard | List of CredentialRequest objects (which encode which credentials you're asking for) | See CredentialRequest example |
content.title | optional | enum | Title Case | "Signup" | What word should be displayed after "1-Click" (accepted values are Signup , Login , Verify , and Apply ) | "Verify" |
content.description | optional | string | Sentence case | none | What text should be displayed under the 1-Click page title | "Confirm your new Hooli account info:" |
redirectUrl | optional | string | URL | defined for your brand in the Dashboard | Overrides the default redirect URL in your brand settings | "https://hooli.com/verifiedAlternate" |
Default Credential Requests
If you don't include credentialRequests
in the request body, the default credential requests will apply. These include the core KYC data points, all set to optional and allowing user input.
Default
[
{
"type": "FullNameCredential",
"mandatory": "no",
"allowUserInput": true,
"children": [
{
"type": "FirstNameCredential"
},
{
"type": "MiddleNameCredential"
},
{
"type": "LastNameCredential"
}
]
},
{
"type": "PhoneCredential",
"mandatory": "no",
"allowUserInput": true
},
{
"type": "AddressCredential",
"mandatory": "no",
"allowUserInput": true,
"children": [
{
"type": "Line1Credential"
},
{
"type": "Line2Credential"
},
{
"type": "CityCredential"
},
{
"type": "StateCredential"
},
{
"type": "CountryCredential"
},
{
"type": "ZipCodeCredential"
}
],
"multi": true
},
{
"type": "BirthDateCredential",
"mandatory": "no",
"allowUserInput": true
},
{
"type": "SsnCredential",
"mandatory": "no",
"allowUserInput": true
}
]
With the Semi-Hosted tab active above, your brand's integration type setting should be set to Semi-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
{
phone: string,
email?: string,
birthDate?: string,
credentialRequests?: CredentialRequest[]
}
Property | Required? | Type | Format | Default | Description | Example |
---|---|---|---|---|---|---|
phone | required | string | E.164 | none | User's phone number (in E.164 format) | "+10123456789" |
email | optional | string | none | User's email address | "richard@piedpiper.net" | |
birthDate | optional | string | YYYY-MM-DD | none | User's birth date (in Sandbox, this must be "1989-08-01" to pass validation) | "1989-08-01" |
credentialRequests | optional | CredentialRequest[] | See CredentialRequest | Defined by the default credential requests brand setting in your Dashboard | List of CredentialRequest objects (which encode which credentials you're asking for) | See CredentialRequest example |
Default Credential Requests
If you don't include credentialRequests
in the request body, the default credential requests will apply. These include the core KYC data points, all set to optional.
Default
[
{
"type": "FullNameCredential",
"mandatory": "no",
"children": [
{
"type": "FirstNameCredential"
},
{
"type": "MiddleNameCredential"
},
{
"type": "LastNameCredential"
}
]
},
{
"type": "PhoneCredential",
"mandatory": "no"
},
{
"type": "AddressCredential",
"mandatory": "no",
"children": [
{
"type": "Line1Credential"
},
{
"type": "Line2Credential"
},
{
"type": "CityCredential"
},
{
"type": "StateCredential"
},
{
"type": "CountryCredential"
},
{
"type": "ZipCodeCredential"
}
]
},
{
"type": "BirthDateCredential",
"mandatory": "no"
},
{
"type": "SsnCredential",
"mandatory": "no"
}
]
With the Non-Hosted tab active above, your brand's integration type setting should be set to Non-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
{
phone: string,
email?: string,
birthDate?: string,
credentialRequests?: CredentialRequest[]
}
Property | Required? | Type | Format | Default | Description | Example |
---|---|---|---|---|---|---|
phone | required | string | E.164 | none | User's phone number (in E.164 format) | "+10123456789" |
email | optional | string | none | User's email address | "richard@piedpiper.net" | |
birthDate | optional | string | YYYY-MM-DD | none | User's birth date (in Sandbox, this must be "1989-08-01" to pass validation) | "1989-08-01" |
credentialRequests | optional | CredentialRequest[] | See CredentialRequest | Defined by the default credential requests brand setting in your Dashboard | List of CredentialRequest objects (which encode which credentials you're asking for) | See CredentialRequest example |
Default Credential Requests
If you don't include credentialRequests
in the request body, the default credential requests will apply. These include the core KYC data points, all set to optional.
Default
[
{
"type": "FullNameCredential",
"mandatory": "no",
"children": [
{
"type": "FirstNameCredential"
},
{
"type": "MiddleNameCredential"
},
{
"type": "LastNameCredential"
}
]
},
{
"type": "PhoneCredential",
"mandatory": "no"
},
{
"type": "AddressCredential",
"mandatory": "no",
"children": [
{
"type": "Line1Credential"
},
{
"type": "Line2Credential"
},
{
"type": "CityCredential"
},
{
"type": "StateCredential"
},
{
"type": "CountryCredential"
},
{
"type": "ZipCodeCredential"
}
]
},
{
"type": "BirthDateCredential",
"mandatory": "no"
},
{
"type": "SsnCredential",
"mandatory": "no"
}
]
Response
Full Definition
We recommend looking at the partial definitions below under the integration type tabs (Hosted, Semi-Hosted, and Non-Hosted) because they show only the properties relevant to the integration type you choose. The full definition here shows all possible properties, but some may not be relevant to your integration type.
{
uuid: string,
url?: string,
code?: string,
identity?: 1ClickEntity
}
Property | Type | Format | Description | Example |
---|---|---|---|---|
uuid | string | Version 4 UUID | Unique identifier for the 1ClickEntity that will be returned at the end of the 1-Click Signup flow | "535dba63-d4bd-442a-b3f6-21b785260a08" |
url | string | URL | Link to the Verified Wallet, which will prompt the user to enter their verification code, display the user's data to them, and ask the user to share the data with your brand | "https://wallet.verified.inc/request/e009d01e-b155-480b-b288-2c9084ab863a?phone=%2B10123456789" |
code | string | 6 digits (0-9) | Verification code you should send to the user by SMS | "111111" |
identity | 1ClickEntity | See 1ClickEntity | A 1ClickEntity object, which contains the user's verified data and metadata about it | See below |
- Hosted
- Semi-Hosted
- Non-Hosted
With the Hosted tab active above, your brand's integration type setting should be set to Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
{
uuid: string,
url: string,
code: string
}
Property | Type | Format | Description | Example |
---|---|---|---|---|
uuid | string | Version 4 UUID | Unique identifier for the 1ClickEntity that will be returned at the end of the 1-Click Signup flow | "535dba63-d4bd-442a-b3f6-21b785260a08" |
url | string | URL | Link to the Verified Wallet, which will prompt the user to enter their verification code, display the user's data to them, and ask the user to share the data with your brand | "https://wallet.verified.inc/request/e009d01e-b155-480b-b288-2c9084ab863a?phone=%2B10123456789" |
code | string | 6 digits (0-9) | Verification code you should send to the user by SMS | "111111" |
With the Semi-Hosted tab active above, your brand's integration type setting should be set to Semi-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
{
uuid: string,
code: string
}
Property | Type | Format | Description | Example |
---|---|---|---|---|
uuid | string | Version 4 UUID | Unique identifier for the 1ClickEntity that will be returned at the end of the 1-Click Signup flow | "535dba63-d4bd-442a-b3f6-21b785260a08" |
code | string | 6 digits (0-9) | Verification code you should send to the user by SMS | "111111" |
With the Non-Hosted tab active above, your brand's integration type setting should be set to Non-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
{
uuid: string,
identity: 1ClickEntity
}
Property | Type | Format | Description | Example |
---|---|---|---|---|
uuid | string | Version 4 UUID | Unique identifier for the 1ClickEntity that will be returned at the end of the 1-Click Signup flow | "535dba63-d4bd-442a-b3f6-21b785260a08" |
identity | 1ClickEntity | See 1ClickEntity | A 1ClickEntity object, which contains the user's verified data and metadata about it | See below |
GET /1-click
Get data for a user who has completed a 1-Click Signup flow
Method | GET |
---|---|
Path | /1-click/{uuid}?code={userInput} |
Request
- Hosted
- Semi-Hosted
- Non-Hosted
With the Hosted tab active above, your brand's integration type setting should be set to Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
Call:
GET /1-click/{identityUuid}
- For the
{uuid}
endpoint path parameter, use the value of theidentityUuid
URL parameter from the redirect URL. - The
{userInput}
endpoint URL parameter isn't relevant here.
With the Semi-Hosted tab active above, your brand's integration type setting should be set to Semi-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
Call:
GET /1-click/{uuid}?code={userInput}
- For the
{uuid}
endpoint path parameter, use the value ofuuid
from the response body ofPOST /1-click
. - For the
{userInput}
endpoint URL parameter, use the value the user inputted when you prompted them to enter their verification code.
Do NOT use code
from the response body of POST /1-click
as the value for userInput
! You must use what the user inputted, so that only the user who controls the phone number can retrieve their verified data. If they enter the correct verification code, of course, it will match the value of code
.
With the Non-Hosted tab active above, your brand's integration type setting should be set to Non-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
There's no need to call GET /1-click
if your brand's integration type is Non-Hosted, because the response body of POST /1-click
contains the same 1ClickEntity
.
However, if you'd like to retrieve the same data again, you can call:
GET /1-click/{uuid}
- For the
{uuid}
endpoint path parameter, use the value ofuuid
from the response body ofPOST /1-click
. - The
{userInput}
endpoint URL parameter isn't relevant here.
Response
{
...1ClickEntity
}
See 1ClickEntity
.
PATCH /1-click
Pass additional information about a user to complete a 1-Click Signup flow
Method | PATCH |
---|---|
Path | /1-click/{uuid} |
Request
- Hosted
- Semi-Hosted
- Non-Hosted
With the Hosted tab active above, your brand's integration type setting should be set to Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
There's no need to call PATCH /1-click
if your brand's integration type is Hosted, because our web app handles collecting additional information (birth date) from the user if it's required — see here.
For a Hosted integration, you should only use POST /1-click
and GET /1-click
.
With the Semi-Hosted tab active above, your brand's integration type setting should be set to Semi-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
Call:
PATCH /1-click/{uuid}
- For the
{uuid}
endpoint path parameter, use the value ofuuid
from the response body ofPOST /1-click
.
Use this request body:
{
birthDate: string
}
Property | Required? | Type | Format | Default | Description | Example |
---|---|---|---|---|---|---|
birthDate | optional | string | YYYY-MM-DD | none | User's birth date | "1989-08-01" |
You must make the PATCH /1-click/{uuid}
call within 30 minutes of having made the POST /1-click
that returned uuid
. Otherwise, you'll get an error that the 1-Click request expired (OCE014
error code).
With the Non-Hosted tab active above, your brand's integration type setting should be set to Non-Hosted in the Dashboard. See Determine integration type if you need help deciding which type is right for you.
There's no need to call PATCH /1-click
if your brand's integration type is Non-Hosted, because the request body of POST /1-click
accepts a birthDate
input, and its response body contains the same 1ClickEntity
that would be returned by PATCH /1-click
.
For a Non-Hosted integration, you should only use POST /1-click
.
Response
{
...1ClickEntity
}
See 1ClickEntity
.