Skip to main content
Social login, magic links, and password resets all send the user back to a URL you choose (redirectTo / redirect_url). Because that trip carries sign-in credentials, Gately only redirects to URLs your project owns. Anything else is rejected with an error before any email is sent or any session is issued.

​
What’s allowed

A redirect URL is accepted when its host is one of: Everything else must use https.
Allowed redirect origins match the full origin: scheme, host, and port. https://acme.com does not allow https://www.acme.com or https://shop.acme.com; add each origin you redirect to.

​
Adding your site

If your login page lives on a domain that isn’t already a custom domain or redirect rule (for example a Framer, Webflow, or Next.js site), add its origin:
  1. Go to Settings → Social Sign-On in your dashboard
  2. Under Allowed redirect origins, add each origin users sign in from, for example https://acme.com and https://www.acme.com
  3. Save
Relative URLs passed to the SDK (redirectTo: '/dashboard') are resolved against the current page, so they work as long as the current site’s origin is allowed.

​
When a redirect isn’t allowed

The request fails with 400:
  • Social login: the error is returned when the login starts, before the user reaches Google or GitHub.
  • Magic links and password resets: the request is rejected and no email is sent.

​
How social login hands back the session

After Google or GitHub sign-in, Gately redirects to your URL with a short-lived, single-use gately_code parameter. The SDK exchanges it for the session automatically and removes it from the address bar, so access tokens never appear in URLs, browser history, or server logs. If you aren’t using the SDK, see Social Login → Without the SDK.