Ory Network does not allow setting CORS origins to

*

,

null

, or

localhost/127.0.0.1

, and this restriction also applies to custom schemes like

<capacitor://localhost>

. The documentation explicitly states that only valid HTTPS origins are allowed, and for local development, you should use [Ory Tunnel](https://www.ory.sh/docs/cli/ory-tunnel#ory-tunnel) instead. Wildcard subdomains (e.g.,

https://*.foobar.ory

) are supported, but custom schemes like

capacitor://

are not accepted as valid CORS origins in the Ory Console or via the API. This is why you receive an error when trying to add

<capacitor://localhost>

as an allowed origin. For mobile app development with Capacitor, you may need to consider alternative approaches, such as using Ory Tunnel during development or deploying your web assets to a domain that can be whitelisted, then loading them in the Capacitor WebView from that domain. There is no documented support for custom schemes like

capacitor://

in Ory's CORS configuration at this time [Set up CORS for Ory Network](https://www.ory.sh/docs/guides/cors) | [Set up custom domains](https://www.ory.sh/docs/guides/custom-domains). If you need to test locally, Ory recommends using Ory Tunnel, which proxies requests and handles CORS for you during development [Ory Tunnel](https://www.ory.sh/docs/cli/ory-tunnel#ory-tunnel).

Ory does support mobile and hybrid apps, but there are important limitations and requirements regarding CORS and cookie handling due to browser security models. For production hybrid mobile apps (such as those built with Capacitor or Cordova), the main challenge is that Ory Network’s CORS configuration does not allow custom schemes like

<capacitor://localhost>

or

localhost

as valid origins. Only HTTPS origins can be whitelisted for CORS. This means you cannot directly use the WebView’s local origin in production with Ory’s hosted APIs [Set up CORS for Ory Network](https://www.ory.sh/docs/guides/cors) | [Set up custom domains](https://www.ory.sh/docs/guides/custom-domains). However, Ory does support native and mobile apps by providing a separate set of API endpoints specifically for native applications. These endpoints do not require CSRF cookies and are designed to work with mobile clients. For native apps, you should use the

/self-service/{flow-type}/api

endpoints, which do not rely on browser cookies or CORS in the same way as browser-based flows [Integration basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration) | [Browser vs. native apps](https://www.ory.sh/docs/identities/native-browser). Key points: - For browser-based flows (including hybrid apps using a WebView), Ory expects the app and Ory APIs to be on the same domain or a CORS-allowed domain, which must be HTTPS and not a custom scheme. - For native flows, use the API endpoints intended for native apps, which do not require CORS or cookies in the same way. - Ory Tunnel is only for local development, not for production [Ory Tunnel](https://www.ory.sh/docs/cli/ory-tunnel#ory-tunnel). In summary: You do not need to build a proxy server, but you must use the native app endpoints for your hybrid app in production. If your hybrid app relies on browser-based flows and cookies, you will run into CORS and cookie domain limitations unless you serve your app from a real HTTPS domain that can be whitelisted. If you use the native app endpoints, you can avoid these issues, but you may need to adapt your authentication flow accordingly [Integration basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration) | [Browser vs. native apps](https://www.ory.sh/docs/identities/native-browser). If you need more specific guidance for your hybrid app’s architecture, please provide details about how authentication is currently implemented in your app.

According to the Ory documentation, using native app endpoints (

/self-service/{flow-type}/api

) in a browser context is explicitly discouraged and prevented by Ory. The docs state: > Because it is very dangerous to use native app endpoints in a browser context, Ory prevents you from using these APIs in the browser. A Capacitor app runs your web code inside a WebView, which is essentially a browser environment. Therefore, from Ory's perspective, a Capacitor app is treated as a browser context, not as a true native app. As a result, you cannot use the native app endpoints in a Capacitor WebView, and Ory will block such requests [Browser vs. native apps](https://www.ory.sh/docs/identities/native-browser). If you need to use Ory in a Capacitor app, you must use the browser endpoints and ensure your app is served from an HTTPS domain that can be whitelisted for CORS. Using the native endpoints in a WebView is not supported and is considered insecure by Ory. Summary: No, you cannot use the native app endpoints in a Capacitor WebView. Ory treats the WebView as a browser and will prevent access to those endpoints for security reasons [Browser vs. native apps](https://www.ory.sh/docs/identities/native-browser).

@chilly-king-10285 but this browser context is within a native app. This is a hybrid app.

You are correct that a hybrid app like one built with Capacitor runs inside a native shell, but the Ory documentation is explicit: Ory treats any WebView (including those in hybrid apps) as a browser context. The documentation states: > Because it is very dangerous to use native app endpoints in a browser context, Ory prevents you from using these APIs in the browser. A WebView, even when embedded in a native app, is considered a browser context by Ory. This means you **cannot use the native app (

/api

) endpoints in a Capacitor WebView**—Ory will block these requests for security reasons. The distinction is not about whether the app is distributed as a native binary, but about the execution environment: if it’s a browser or WebView, it is subject to browser security rules and Ory’s restrictions [Browser vs. native apps](https://www.ory.sh/docs/identities/native-browser). In summary: Even though your hybrid app is running inside a native shell, Ory does not allow the use of native app endpoints from within a WebView. You must use the browser endpoints and comply with CORS and cookie requirements as you would for any web application.