If your product has a browser component, the best practice is to include a redirect URI. The redirect URI allows the PIN to be communicated transparently so that the user doesn't need to enter it manually. The redirect URI should point to a site on your server or in your cloud.
One common use case for a redirect URI is to bring up a page that has a structure picker, allowing the user to select a primary residence or a vacation home, for example.
Another example might be a deep link within your mobile app.
A third example is when the validation accepts localhost. In this case, the URI doesn't actually function as a redirect, but takes the authorization code and uses it to exchange for a token.
Use multiple redirect URIs
With multiple redirect URIs, a Works with Nest single client can be released to multiple locales or tested in different environments, each with its own URI.
Typically, applications are deployed to multiple sites:
- Production sites
- Sites where you perform local development
- Test servers where you perform different testing activities
It makes sense to set up multiple redirect URIs in your Works with Nest client so that you can have multiple locales, multiple app types (web, mobile), and mobile deep linking with platform-specific URIs.
Set up deep links
For deep links, your URIs must conform to the RFC 3986 URI standard and must not
In general, the custom URI scheme in string form has the syntax:
Some examples are:
Set up redirect URIs
In the client configuration, specify multiple (up to 10) redirect URIs. URIs can have up to 2083 characters.
In the authorization URL, include the
- Default URI—
- Additional redirect URIs—
In the authorization URL, make sure to URL-encode the URI by running the
$ urlencode http://localhost:3000 http%3A%2F%2Flocalhost%3A3000
You can then use this encoded version in the authorization URL, as shown here:
If you omit the
redirect_uri query parameter, the default redirect URI is
So in our example:
is equivalent to having no