We recommend using wildcards only for non-production purposes, as they present increased security risk.

- Root level domains are not allowed (.com is not allowed). - Only a single wildcard is allowed per callback (https://..hello.com is not allowed). - Wildcards are only allowed with http or https URL protocols (.hello.com, service:jmx:rmi://[host[:port]][urlPath] are not allowed). - Wildcard has to be in the leftmost subdomain (https://*.hello.com is allowed, https://hello.*.com is not allowed). - Wildcards with prefixes and suffixes are allowed (https://prefix-*-suffix.hello.com) - A URL with a valid wildcard will not match a URL with more than one subdomain level in place of the wildcard. (https://*.hello.com will not work with https://sub1.sub2.hello.com) - Certain well-known shared hosting domains require a suffix or prefix for the wildcard (*.vercel.app is not allowed as this opens up anyone to authenticate on the Vercel platform, but *something.vercel.app is allowed as this will lock callbacks to your team or personal account). - Wildcards are not supported as part of a URL path (https://sub1.sub2.hello.com/* is not allowed). You can use the post-login redirect (available in several SDKs) to achieve dynamic navigation after authentication.

Troubleshoot ‘Invalid callback URL’ - A common error reported by new users is that they receive an ‘invalid callback URL’ message when testing their connection. If you get this error, check the following: - Make sure there are no spaces before or after the callback URL in your Kinde application. - Ensure the callback URL in your code exactly matches the callback URL in your Kinde application. - The Client ID in your code must exactly match the Client ID in your Kinde application. - If you’re testing with a cloud hosting solution, such as Vercel, redeploy your application each time you update the environment variables.