Wildcards in Callback URLs

Back in January 2023 we announced that developers could specify multiple callback URLs for their applications. This feature is useful in situations where you want to be able to use the same application in different environments, for example, with one domain as a staging environment, and another domain as a production environment.

Now, something you may not know yet is that you can also use wildcards in the callback URL, for example, https://*.mydomain.com/auth/callback. This would effectively cover all 3 callbacks specified in the screenshot above. The wildcards can be used under the following conditions:

• They can only be used in the top subdomain (for example, https://*.mydomain.com/callback and https://*foo.mydomain.com/callback are valid, but https://www.*.com/callback is not)
• They can only be used with the HTTPS protocol
• They cannot be used with localhost

Callback State

If there's any other information you would like to include in your callbacks, note that instead of including this data in the URL, you can actually use the state parameter in the authorization request. The parameter may contain arbitrary URL-encoded data. As an example, the following authorization request includes a JSON payload {"env":"staging"} (encoded as %7B%22env%22%3A%22staging%22%7D) in the state:

https://developer.api.autodesk.com/authentication/v2/authorize?response_type=code&client_id=foo&redirect_uri=http%3A%2F%2Fwww.mydomain.com%2Fauth%2Fcallback&nonce=12321321&scope=data:read&prompt=login&state=%7B%22env%22%3A%22staging%22%7D

Path Wildcards

Note that for some time it was also possible to use wildcards in the path of the URL (for example, https://www.mydomain.com/*), however this feature was later removed. If you created this kind of callback URL before this restriction, it will continue to work. Any newly created callback URLs will need to adhere to the conditions listed above.