Migration Guide (v1 to v2)
This Migration Guide will help you migrate from 1-Click Signup v1 to v2.
Time to Migrate | 30 minutes |
---|---|
Time to Test and Deploy | 30 minutes |
Background
1-Click Signup v2 is a major improvement over v1:
- Over 3x faster! API call response times are much faster, which will increase your signup flow's conversion.
- Self service: You can manage your API keys and brand settings via our Dashboard, instead of having to ask us to make changes for you.
- Easier to use: We've further simplified the API, so in v2 it's even easier to use.
Setup
1. Log into Dashboard.
Access the Verified Dashboard.
a. Enter your email and click the 1-Click Login button.
We'll send you a verification code by email.
Use your work email. We use AI magic to autofill brand information based on your email domain, so you don't have to manually enter it!
b. Complete the verification step.
Click the verification button in the email or enter the verification code. We'll automatically log you in. It's a 1-click experience, as promised!
c. (if necessary) Confirm your company name.
If you're creating the Dashboard account for your company, we'll ask you to confirm your company name. If someone on your team has already created your account, you won't need to do this.
If your account doesn't have a brand yet, we'll automatically create one for you and take you to its Brand Details page.
Your company account can have one or more brands. Generally, you'll only need one brand, but there are some cases where it's helpful to use multiple. For example:
- If you have multiple products: If you have products that go by different names, it can be useful to create different brands to help users know which product they're using 1-Click Signup for — and to help your team track metrics specific to that product.
- If you want to try different brand settings: If you want to change brand settings without affecting your existing implementation (even in Sandbox), you can duplicate your brand and configure different settings on the new brand.
Migration
Migrating from v1 to v2 is simple and easy. How to do so depends on which variant of v1 you implemented:
- If you implemented the v1 hosted variant (the default) → Select the From v1 Hosted Variant tab below.
- If you implemented the v1 non-hosted variant (described in this section) → Select the From v1 Non-Hosted Variant tab below.
- If you implemented the v1 trusted variant (described in this section) → Select the From v1 Trusted Variant tab below.
- From v1 Hosted Variant
- From v1 Non-Hosted Variant
- From v1 Trusted Variant
If you implemented 1-Click Signup v1 using the hosted variant (the default), you should migrate to v2 where your brand's integration type is set to Hosted. For more information on integration types, see Determine integration type in the Integration Guide.
The steps below explain how to do this. Refer to the Integration Guide for additional details.
1. Configure brand settings.
Under Brand Settings, set your brand's integration type to Hosted.
Make sure the rest of the settings for your brand are accurate. The Dashboard tries to autofill values based on your email domain to save you time, but you may need to manually adjust some settings — in particular the terms, privacy, and default redirect URLs.
2. Update Verified API calls.
a. Update Sandbox base URL and API key.
Append the /v2
path to the Sandbox base URL for your Verified API calls, and replace your old Sandbox API key with the v2 Sandbox API key for your brand. You can copy this API key from the top of the Brand Details page in the Dashboard.
In v1, you had to include your API key as a bearer token in the authorization header. In v2, you should include your API key directly, not as a bearer token: just remove Bearer
from the authorization header.
Version | Base URL | Authorization Header |
---|---|---|
v1 | https://core-api.sandbox-verifiedinc.com | Authorization: Bearer |
v2 | https://core-api.sandbox-verifiedinc.com/v2 | Authorization: |
The Sandbox domain is sandbox-verifiedinc.com
but the Production domain is verified.inc
.
Wait to update the Production base URL and API key until you're ready to go live.
b. Update POST /1-click
.
Request:
- Remove
verificationOptions
, which is deprecated in v2.- In v1,
verificationOptions
lets you specify whethersmsBody
in the response body should contain a verification code, verification link, or both. - In v2, only a verification
code
is returned. See Usecode
instead ofsmsBody
below for how to use it.
- In v1,
- Remove
isHosted?
, which is replaced in v2 by the integration type brand setting (which you set to Hosted in Step 2).
You may not have been using these properties in v1 because they're both optional (verificationOptions
defaults to only_code
and isHosted?
defaults to true
). If you weren't using them, you don't need to change anything in the request body!
Response:
-
Stop using
match
, which is not returned in v2.- In v1,
match
is an explicit indicator of whether we can source data for a user. It's redundant because whether the response is an error is an implicit indicator. - In v2, there's only the implicit indicator of whether the response is an error.
- In v1,
-
Use
code
instead ofsmsBody
, which is not returned in v2.-
In v1,
smsBody
includes a verification code and/or link inside our recommended language, so you can directly sendsmsBody
in an SMS to the user. (The verification link is a link to our Verified Wallet containing the verification code.) -
In v2, only
code
is returned, so you have more flexibility in what language you use for the SMS. This means you need to construct the SMS body yourself. We recommend using this language, where{Brand Name}
is your brand name:Enter this code to verify for
{Brand Name}
:code
For example:
Enter this code to verify for Hooli: 123456
-
-
Send the user an SMS containing
code
, since we don't send SMS in Sandbox in v2.- In v1, we send SMS for you in Sandbox. This makes it easier to test initially, but it ultimately complicates the integration process because we can't send SMS for you in Production (due to US SMS regulations).
- In v2, we've eliminated this difference: we no longer send SMS for you in Sandbox (and we still don't in Production). So, you need to send SMS yourself in Sandbox as part of your testing process.
You can also optionally use code
to construct a verification link. For example, if url
is a link to your application, you could:
- Append
code
as a URL parameter tourl
:{url}?code={code}
. - Set up your application to parse
code
from the URL.
Then, you could include language like this in the SMS:
Click this link to verify for
{Brand Name}
:{url}?code={code}
For example, if the url
for the Hooli brand is https://hooli.com/verified
:
Click this link to verify for Hooli: https://hooli.com/verified?code=123456
In v1, the verification code is formatted as 6 digits with a hyphen in the middle, like 111-111
.
In v2, the verification code is formatted as just 6 digits, like 111111
, so you can more easily present the code in the format that's best for your use case.
We still generally recommend including a hyphen in the middle because it helps the user read and remember the code if they need to. (2 groups of 3 digits is easier to parse than 6 digits in a block.)
c. Update GET /1-click
.
Request:
- Use
identityUuid
instead of1ClickUuid
, which is renamed in v2.- In v1, we add a
1ClickUuid
URL parameter to the URL we redirect the user to at the end of the 1-Click Signup flow. - In v2, this is renamed
identityUuid
, so you should update your URL parsing code.
- In v1, we add a
Response: The response is the same for v2 as for v1, so no need to update anything there!
3. Go live!
a. Sync brand settings to Production.
On the Brand Details page in the Dashboard, click the Sync to Production button to sync your brand's settings from Sandbox to Production.
b. Update Production base URL and API key.
Append the /v2
path to the Production base URL for your Verified API calls, and replace your old Production API key with the v2 Production API key for your brand. You can copy this API key from the top of the Brand Details page in the Dashboard.
Version | Base URL |
---|---|
v1 | https://core-api.verified.inc |
v2 | https://core-api.verified.inc/v2 |
The Sandbox domain is sandbox-verifiedinc.com
but the Production domain is verified.inc
.
For you to be able to create Production API keys, we need to approve your customer account. If you need us to do so, reach out to us at Support@Verified.inc.
c. Complete Go Live checklist and deploy.
Ensure you've completed the items in the Go Live checklist in the Integration Guide.
When you've done so, deploy 1-Click Signup v2!
If you implemented 1-Click Signup v1 using the non-hosted variant (described in this section of the 1-Click Signup v1 guide), you should migrate to v2 where your brand's integration type is set to Semi-Hosted. For more information on integration types, see Determine integration type in the Integration Guide.
The steps below explain how to do this. Refer to the Integration Guide for additional details.
1. Configure brand settings.
Under Brand Settings, set your brand's integration type to Semi-Hosted.
2. Update Verified API calls.
a. Update Sandbox base URL and API key.
Append the /v2
path to the Sandbox base URL for your Verified API calls, and replace your old Sandbox API key with the v2 Sandbox API key for your brand. You can copy this API key from the top of the Brand Details page in the Dashboard.
In v1, you had to include your API key as a bearer token in the authorization header. In v2, you should include your API key directly, not as a bearer token: just remove Bearer
from the authorization header.
Version | Base URL | Authorization Header |
---|---|---|
v1 | https://core-api.sandbox-verifiedinc.com | Authorization: Bearer |
v2 | https://core-api.sandbox-verifiedinc.com/v2 | Authorization: |
The Sandbox domain is sandbox-verifiedinc.com
but the Production domain is verified.inc
.
Wait to update the Production base URL and API key until you're ready to go live.
b. Update POST /1-click
.
Request:
- Remove
verificationOptions
, which is deprecated in v2.- In v1,
verificationOptions
lets you specify whethersmsBody
in the response body should contain a verification code, verification link, or both. - In v2, only a verification
code
is returned. See Usecode
instead ofsmsBody
below for how to use it.
- In v1,
- Remove
isHosted?
, which is replaced in v2 by the integration type brand setting (which you set to Hosted in Step 2).
You may not have been using these properties in v1 because they're both optional (verificationOptions
defaults to only_code
and isHosted?
defaults to true
). If you weren't using them, you don't need to change anything in the request body!
Response:
-
Stop using
match
, which is not returned in v2.- In v1,
match
is an explicit indicator of whether we can source data for a user. It's redundant because whether the response is an error is an implicit indicator. - In v2, there's only the implicit indicator of whether the response is an error.
- In v1,
-
Stop using
url
, which is not returned in v2.- In v1, you append what the user inputs for the verification code (let's call it
userInput
) tourl
and then redirect the user to the resulting link, which verifies the user's input and then redirects them back to you. - In v2, there's no need for such a redirect, so
url
is not returned. Instead, you passuserInput
toGET /1-click
(see UpdateGET /1-click
below).
- In v1, you append what the user inputs for the verification code (let's call it
-
Use
code
instead ofsmsBody
, which is not returned in v2.-
In v1,
smsBody
includes a verification code and/or link inside our recommended language, so you can directly sendsmsBody
in an SMS to the user. (The verification link is a link to our Verified Wallet containing the verification code.) -
In v2, only
code
is returned, so you have more flexibility in what language you use for the SMS. This means you need to construct the SMS body yourself. We recommend using this language, where{Brand Name}
is your brand name:Enter this code to verify for
{Brand Name}
:code
For example:
Enter this code to verify for Hooli: 123456
-
-
Send the user an SMS containing
code
, since we don't send SMS in Sandbox in v2.- In v1, we send SMS for you in Sandbox. This makes it easier to test initially, but it ultimately complicates the integration process because we can't send SMS for you in Production (due to US SMS regulations).
- In v2, we've eliminated this difference: we no longer send SMS for you in Sandbox (and we still don't in Production). So, you need to send SMS yourself in Sandbox as part of your testing process.
You can also optionally use code
to construct a verification link. For example, if url
is a link to your application, you could:
- Append
code
as a URL parameter tourl
:{url}?code={code}
. - Set up your application to parse
code
from the URL.
Then, you could include language like this in the SMS:
Click this link to verify for
{Brand Name}
:{url}?code={code}
For example, if the url
for the Hooli brand is https://hooli.com/verified
:
Click this link to verify for Hooli: https://hooli.com/verified?code=123456
In v1, the verification code is formatted as 6 digits with a hyphen in the middle, like 111-111
.
In v2, the verification code is formatted as just 6 digits, like 111111
, so you can more easily present the code in the format that's best for your use case.
We still generally recommend including a hyphen in the middle because it helps the user read and remember the code if they need to. (2 groups of 3 digits is easier to parse than 6 digits in a block.)
c. Update GET /1-click
.
Request:
- Add
userInput
as a parameter to callGET /1-click/{uuid}?{userInput}
.- In v1, you append what the user inputs for the verification code (let's call it
userInput
) tourl
and then redirect the user to the resulting link, which verifies the user's input and then redirects them back to you. - In v2, you instead include
userInput
as a parameter on theGET /1-click
API call. There's no need for a redirect.
- In v1, you append what the user inputs for the verification code (let's call it
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
.
Response: The response is the same for v2 as for v1, so no need to update anything there!
3. Go live!
a. Sync brand settings to Production.
On the Brand Details page in the Dashboard, click the Sync to Production button to sync your brand's settings from Sandbox to Production.
b. Update Production base URL and API key.
Append the /v2
path to the Production base URL for your Verified API calls, and replace your old Production API key with the v2 Production API key for your brand. You can copy this API key from the top of the Brand Details page in the Dashboard.
Version | Base URL |
---|---|
v1 | https://core-api.verified.inc |
v2 | https://core-api.verified.inc/v2 |
The Sandbox domain is sandbox-verifiedinc.com
but the Production domain is verified.inc
.
For you to be able to create Production API keys, we need to approve your customer account. If you need us to do so, reach out to us at Support@Verified.inc.
c. Complete Go Live checklist and deploy.
Ensure you've completed the items in the Go Live checklist in the Integration Guide.
When you've done so, deploy 1-Click Signup v2!
If you implemented 1-Click Signup v1 using the trusted variant (described in this section of the 1-Click Signup v1 guide), you should migrate to v2 where your brand's integration type is set to Non-Hosted. For more information on integration types, see Determine integration type in the Integration Guide.
The steps below explain how to do this. Refer to the Integration Guide for additional details.
1. Configure brand settings.
Under Brand Settings, set your brand's integration type to Non-Hosted.
2. Update Verified API calls.
a. Update Sandbox base URL and API key.
Append the /v2
path to the Sandbox base URL for your Verified API calls, and replace your old Sandbox API key with the v2 Sandbox API key for your brand. You can copy this API key from the top of the Brand Details page in the Dashboard.
In v1, you had to include your API key as a bearer token in the authorization header. In v2, you should include your API key directly, not as a bearer token: just remove Bearer
from the authorization header.
Version | Base URL | Authorization Header |
---|---|---|
v1 | https://core-api.sandbox-verifiedinc.com | Authorization: Bearer |
v2 | https://core-api.sandbox-verifiedinc.com/v2 | Authorization: |
The Sandbox domain is sandbox-verifiedinc.com
but the Production domain is verified.inc
.
Wait to update the Production base URL and API key until you're ready to go live.
b. Switch from POST /1-click/trusted
to POST /1-click
.
POST /1-click/trusted
is deprecated in v2.
- In v1, you use this separate endpoint.
- In v2, you instead set your brand's integration type to Non-Hosted and use the base
POST /1-click
endpoint.
Request: The request body is the same for v2 POST /1-click
as for v1 POST /1-click/trusted
, so no need to update anything there!
Response:
- Use the
identity
key to access data. The data is structured in exactly the same way as in v1, but in v2 it's keyed onidentity
(see here).
3. Go live!
a. Sync brand settings to Production.
On the Brand Details page in the Dashboard, click the Sync to Production button to sync your brand's settings from Sandbox to Production.
b. Update Production base URL and API key.
Append the /v2
path to the Production base URL for your Verified API calls, and replace your old Production API key with the v2 Production API key for your brand. You can copy this API key from the top of the Brand Details page in the Dashboard.
Version | Base URL |
---|---|
v1 | https://core-api.verified.inc |
v2 | https://core-api.verified.inc/v2 |
The Sandbox domain is sandbox-verifiedinc.com
but the Production domain is verified.inc
.
For you to be able to create Production API keys, we need to approve your customer account. If you need us to do so, reach out to us at Support@Verified.inc.
c. Complete Go Live checklist and deploy.
Ensure you've completed the items in the Go Live checklist in the Integration Guide.
When you've done so, deploy 1-Click Signup v2!