Allowed domains

Your app's front end runs on your domain, such as https://yourapp.com, and calls your app's API from the browser. Browsers only let a page on one site read responses from another when the other site agrees, using CORS. Your app's allowed domains are the sites it agrees to.

The same list decides where your sign-in links can go: a magic link, a password-reset link or a Google or GitHub sign-in can return to a page on one of these domains instead of the console's pages (see Send sign-in links to your own pages).

What is allowed

• Your listed domains, on your app's own routes (/{appUid}/…). Each app has its own list: a domain allowed for one app is not allowed for another.
• localhost on any port, over http or https, for every app. Developing against a hosted app from your own machine needs no setup.
• Requests that do not come from a browser page: your servers, scripts and curl send no Origin header, and the list does not apply to them.

Every request is still authenticated as usual: an allowed domain decides which websites a browser lets read your app's responses, and a user's bearer token decides what the request may do.

Add your domains

In the console, open your app, then App settings › Domains. Add each domain, then Save domains.

An entry is an origin: https://, a domain, and a port only when it is not 443. It has no path, query or trailing slash, and the console saves it in lowercase. A wildcard is allowed only as the first label (https://*.yourapp.com). An app can list up to 25 domains; a wildcard covers any number of subdomains in one entry.

A save takes effect on every server within a minute.

What a refused browser sees

A page on a site that is not allowed gets a CORS error in the browser console, such as:

Access to fetch at 'https://api.example.com/<appUid>/invoices' from origin 'https://yourapp.com'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the
requested resource.

Your code sees a failed fetch (TypeError: Failed to fetch) and no response body. The request stops at the edge and does nothing in your app. If you see this from your own site, add the exact origin shown after from origin to your allowed domains.

Send sign-in links to your own pages

By default, sign-in links and the social sign-in callback land on the console's pages. To handle them on your own site, pass redirectTo: an absolute address on one of your allowed domains, or on localhost.

Any query already on redirectTo is kept. Your page reads token (or code) from the address and calls the same endpoint the console's page would: magic-link/verify, confirm-password-reset or oauth/exchange. See Sign-in methods for those calls.

curl -X POST "$AUTHORIC_URL/$APP_UID/auth/magic-link/request" \
  -H "Content-Type: application/json" \
  -d '{ "email": "dana@example.com", "redirectTo": "https://yourapp.com/auth/link" }'

A redirectTo off your allowed domains is refused with 400 REDIRECT_NOT_ALLOWED before any email is sent or any redirect happens, so a link can never be sent to someone else's site. Whether the address has an account still never shows: an accepted request answers the same message either way. For social sign-in, the return address is kept on the server for the length of the sign-in and checked again when the provider sends the user back.

Errors to branch on

Saving the list in the console can answer:

What's next