To trigger a resend flow during registration in Ory, you need to use the registration flow with the

code

method and include the

resend

field in your request. According to the API specification, the

resend

property is available in the "Update Registration Flow with Code Method" and is used to restart the flow with a new code. Your request body should look like this:

json {   "method": "code",   "traits": { /* your identity traits */ },   "csrf_token": "your-csrf-token",   "resend": "true" }

-

method

must be set to

code

. -

traits

should contain the identity's traits. -

csrf_token

is required for browser flows. -

resend

triggers the resend of the code. This will instruct Ory to resend the verification code as part of the registration flow using the code method [Ory API Reference – updateRegistrationFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json). If you are using a custom UI, make sure to include a button or action that submits the registration flow with the

resend

field set, as shown above. > Note: The knowledge sources do not provide a full example of the resend action in a UI, but the API contract clearly supports this field for the code method during registration.

The error

value must be "code"

typically means that the value provided for the

method

field in your request body is not exactly

"code"

(as a string), or the field is missing. According to the Ory API specification, the

method

field must be set to the string

"code"

when using the code method for registration:

json {   "method": "code",   "traits": { /* your identity traits */ },   "csrf_token": "your-csrf-token",   "resend": "true" }

Please check the following: - Ensure that the

method

field is present and its value is exactly

"code"

(all lowercase, no extra spaces or quotes). - Make sure you are not sending the value as a boolean or any other type (e.g., not

method: code

without quotes, or

method: "Code"

with a capital "C"). - The request body must be valid JSON if you are using the

application/json

content type. If you are still seeing the error, double-check the request payload and the content type header. The API expects: -

method

(string, required): must be

"code"

-

traits

(object, required) -

csrf_token

(string, required for browser flows) -

resend

(string, optional) Reference: [Ory API Reference – updateRegistrationFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json) If you are following these requirements and still encounter the error, please provide the exact request payload (with sensitive data redacted) for further troubleshooting.

Thank you for your feedback. Based on the official Ory API documentation, to trigger a resend of the code during registration, you should set the

resend

field to the string value

"code"

in your request payload, not

"true"

. Here is the correct request body format:

json {   "method": "code",   "traits": { /* your identity traits */ },   "csrf_token": "your-csrf-token",   "resend": "code" }

-

method

must be

"code"

. -

traits

should contain the identity's traits. -

csrf_token

is required for browser flows. -

resend

must be set to

"code"

to trigger the resend action. This is confirmed by the API schema, which describes the

resend

field as a string and expects the value

"code"

to restart the flow with a new code [Ory API Reference – updateRegistrationFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json). If you use any other value for

resend

, or omit it, the resend action will not be triggered and you may see the error you described.

To verify a code during the registration flow (when using the code method), you need to submit the code along with the required fields to the registration flow endpoint. According to the Ory API specification, the request body should include: - `method`: must be

"code"

- `code`: the code received by the user - `csrf_token`: required for browser flows - `traits`: the identity's traits Here is an example request body:

json {   "method": "code",   "code": "123456",   "csrf_token": "your-csrf-token",   "traits": { /* your identity traits */ } }

This will submit the code for verification as part of the registration flow. Make sure not to include the

resend

field when you are verifying the code; it is only used to trigger a resend of the code [Ory API Reference – updateRegistrationFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json). If you need to verify a code for other flows (like verification or recovery), the process is similar: submit the code and required fields to the appropriate endpoint, following the same pattern as above.

Ory Kratos and Ory Network provide rate limiting as a defense against brute-force attacks, especially on public endpoints like login and registration. In Ory Network, rate limiting is built-in and managed as part of the platform’s security infrastructure, with both project-level and endpoint-based rate limits. These limits help protect against abuse, credential stuffing, and ensure fair usage. The specific rate limits depend on your subscription plan and environment, and are not directly configurable by users except for IP whitelisting in higher plans [Understand Ory Network rate limiting](https://www.ory.sh/docs/guides/rate-limits) [Threat models and security profiles](https://www.ory.sh/docs/kratos/concepts/security). For self-hosted Ory Kratos, rate limiting is not built-in by default. The documentation and community discussions recommend implementing rate limiting and lockout mechanisms externally, for example, using a Web Application Firewall (WAF) like Cloudflare or Akamai. There have been requests and discussions about adding account lockout and login throttling features directly to Kratos, but these are not currently part of the official release due to complexity and scalability concerns. Some community members have proposed or implemented custom solutions, but the official recommendation is to use external tools for these protections [Throttling repeated login requests & account lock](https://github.com/ory/kratos/issues/3037). Summary: - Ory Network: Rate limiting is built-in and managed by Ory. - Self-hosted Ory Kratos: No built-in rate limiting or lockout; recommended to use external solutions like a WAF. - Account lockout: Not natively supported in Ory Kratos; discussed but not implemented due to complexity. If you need strict lockout or throttling, you should implement it externally or consider using Ory Network, which provides these protections as part of its managed service.

To determine which DSN (database connection string) Ory Kratos is using, you should check the configuration file (typically

kratos.yml

) or the environment variable

DSN

that is set when starting the Kratos service. The DSN is specified under the

dsn

key in the configuration file, for example:

yaml dsn: <postgres://kratos:password@localhost:5432/kratos?sslmode=disable>

Alternatively, if you are running Kratos via Docker, the DSN is often set as an environment variable:

bash -e DSN=<postgres://kratos:password@localhost:5432/kratos?sslmode=disable>

or

bash export DSN=...

and then referenced with the

-e

flag in commands [Docker images](https://www.ory.sh/docs/kratos/guides/docker). To check the status of the database connection, you can use the Kratos health endpoints: -

GET /health/alive

checks if the HTTP server is running (does not check the database connection). -

GET /health/ready

checks if Kratos is running and if the environment dependencies (including the database) are responsive. A 200 OK response means the database connection is healthy; a 503 indicates issues [Ory Identities API - metadata](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json). Example:

bash curl <http://localhost:4433/health/ready>

A successful response:

json {"status":"ok"}

indicates that Kratos is ready and the database connection is healthy. If you need to confirm the exact DSN at runtime, you must inspect the running configuration or environment variables, as Kratos does not expose the DSN via its API for security reasons.

To inspect the running configuration or environment variables for Ory Kratos, you should: 1. Check the configuration file: Ory Kratos loads its configuration from a file (YAML, JSON, or TOML). The path to this file is specified when starting Kratos using the

--config

flag (e.g.,

kratos --config path/to/kratos.yml

). You can open this file directly to see the current configuration, including the

dsn

value [Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring). 2. Check environment variables: Environment variables take precedence over config file values. You can inspect the environment variables of the running Kratos process using standard OS tools (e.g.,

printenv

,

env

, or by inspecting the process environment in your container/orchestration platform). The DSN is typically set as

DSN=...

 [Configuration](https://www.ory.sh/docs/ecosystem/configuring). 3. Note: Ory Kratos does not provide an API endpoint to directly expose the full running configuration or environment variables for security reasons. You must inspect these at the file or process level. If you are running Kratos in Docker, you can check the environment variables set in your

docker run

command or

docker-compose.yml

file. If running in Kubernetes, check your deployment manifests or use

kubectl exec

to inspect the environment inside the running pod. > The knowledge sources do not mention any built-in Kratos API or CLI command to dump the full running configuration or environment variables at runtime.

If you have provided the

dsn

in your

kratos.yml

but Ory Kratos does not seem to be connecting to the database, here are some steps to troubleshoot based on the official documentation: 1. Check for Environment Variable Override Environment variables take precedence over config file values. If you have set the

DSN

environment variable (e.g., in your Docker Compose, shell, or deployment), it will override the value in

kratos.yml

. Make sure there is no conflicting

DSN

environment variable set [Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring). 2. Verify the Configuration File Path Ensure that Kratos is actually loading the correct configuration file. The config file path is specified with the

--config

or

-c

flag when starting Kratos. If the wrong file is loaded, your

dsn

setting may be ignored [Reference: Configuration](https://www.ory.sh/docs/kratos/reference/configuration). 3. Check the DSN Format The DSN must be in the correct format for your database (e.g., PostgreSQL, MySQL). For example, for PostgreSQL:

dsn: <postgres://user:password@host:5432/database?sslmode=disable>

[Self-hosted deployment](https://www.ory.sh/docs/self-hosted/deployment) 4. Check Kratos Logs Start Kratos with a higher log level (e.g.,

LOG_LEVEL=trace

) to get more information about connection attempts and errors. This can help you identify if there are authentication issues, network problems, or misconfigurations. 5. Test Database Connectivity Make sure your database is running and accessible from the environment where Kratos is running. You can test this by connecting to the database manually using the same credentials and host/port. 6. Check Health Endpoint Use the

/health/ready

endpoint to check if Kratos is able to connect to the database:

bash    curl <http://localhost:4433/health/ready>

A 200 OK response means the database connection is healthy; a 503 indicates issues [Deploy to production](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#run-ory-kratos-using-systemd). If after these checks Kratos still does not connect to the database, review your startup command, environment, and logs for any errors or warnings related to configuration or database connectivity. > The knowledge sources do not provide a built-in Kratos API or CLI command to dump the effective configuration at runtime, so you must verify the config file and environment variables directly.

If the

/health/ready

endpoint returns

ok

, it means Ory Kratos is able to connect to its configured database. However, this endpoint does not tell you which database (SQLite, Postgres, etc.) is being used. To determine whether Kratos is using SQLite (the default in many quickstarts) or your custom DSN, you need to: 1. Check your configuration file (

kratos.yml

) for the

dsn

value. For example:

yaml    dsn: <postgres://user:password@host:5432/database?sslmode=disable>

or

yaml    dsn: memory

or

yaml    dsn: sqlite:///tmp/some-db.sqlite?_fk=true

[Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring) 2. Check for environment variable overrides. If the

DSN

environment variable is set, it will override the value in your config file. Environment variables take precedence over config file values [Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring). 3. Review your startup command. Ensure you are passing the correct config file to Kratos using the

--config

or

-c

flag, and that there are no conflicting environment variables. Kratos does not provide an API or CLI command to show the effective DSN at runtime. You must inspect the configuration and environment variables directly to be certain which database is in use. If you want to be sure, temporarily set an invalid DSN in your config or environment and restart Kratos—if the health endpoint fails, you know that DSN is being used. > The knowledge sources do not mention any built-in way to query the current DSN via API or logs, so manual inspection is required.

Your DSN format should follow the standard for PostgreSQL as described in the Ory documentation. The correct format is:

<postgres://user:password@host:port/database?sslmode=disable>

Based on your example,

<postgresql://postgres:admin@x.x.x.x?sslmode=disable>

, there are a couple of issues: 1. Scheme: It should be

postgres://

, not

postgresql://

. 2. Database Name: You are missing the database name in the path section of the DSN. 3. Port: If you are not using the default port (5432), you should specify it. Example of a correct DSN:

<postgres://postgres:admin@x.x.x.x:5432/kratos?sslmode=disable>

Replace

kratos

with your actual database name. Reference: See the official documentation for the correct DSN format and examples: [Self-hosted deployment](https://www.ory.sh/docs/self-hosted/deployment#data-storage-and-persistence) [Deploy to production](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#install-ory-kratos) If your DSN does not match this format, Ory Kratos may not connect to your database as expected.

If you have updated the

dsn

in your configuration but Ory Kratos is still not connecting to your database—and the flows are still working—this strongly suggests that Kratos is not using your intended database configuration. Instead, it is likely falling back to an in-memory or SQLite database. Here are the most probable reasons, based on the official documentation: 1. Environment Variable Override: Environment variables take precedence over config file values. If the

DSN

environment variable is set (for example, in your Docker Compose, shell, or deployment), it will override the value in your

kratos.yml

. Double-check that there is no

DSN

environment variable set elsewhere that points to

memory

or

sqlite

 [Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring). 2. Incorrect Configuration File Path: Ensure that Kratos is loading the correct configuration file. The config file path must be specified with the

--config

or

-c

flag when starting Kratos. If the wrong file is loaded, your

dsn

setting may be ignored [Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring). 3. Default to Memory/SQLite: If Kratos cannot connect to the specified database (e.g., due to a malformed DSN or network issue), it may fail to start or, in some setups, default to an in-memory database. If the flows are working but no data is persisted after a restart, this is a strong indicator that Kratos is using in-memory storage [Self-hosted deployment](https://www.ory.sh/docs/self-hosted/deployment#sqlite). 4. Check the DSN Format: The DSN must be in the correct format. For PostgreSQL, it should look like:

<postgres://user:password@host:port/database?sslmode=disable>

If the DSN is malformed or missing the database name, Kratos will not connect to your intended database [Self-hosted deployment](https://www.ory.sh/docs/self-hosted/deployment#data-storage-and-persistence). What you should do: - Double-check for any

DSN

environment variable overrides. - Confirm the config file path used at startup. - Ensure your DSN is correctly formatted and points to a reachable database. - Check if your data persists after restarting Kratos. If not, it is using in-memory storage. > The knowledge sources do not mention any built-in Kratos API or CLI command to show the effective DSN at runtime, so you must verify the config file and environment variables directly. If you need further troubleshooting, increase the log level (e.g.,

LOG_LEVEL=trace

) to see more details about database connection attempts in the logs [Go to production](https://www.ory.sh/docs/kratos/guides/production).

If you have confirmed that Ory Kratos is using an in-memory database instead of connecting to your configured database, the most likely causes—according to the official documentation—are: 1. Environment Variable Override: The

DSN

environment variable takes precedence over the value in your

kratos.yml

configuration file. If

DSN

is set to

memory

or another value elsewhere (such as in your environment, Docker Compose, or deployment scripts), Kratos will use that instead of your config file setting [Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring). 2. Incorrect Configuration File Usage: Kratos must be started with the correct configuration file using the

--config

or

-c

flag. If the wrong file is loaded, or if the file is not being loaded at all, your

dsn

setting will not be applied [Configure Ory Kratos](https://www.ory.sh/docs/kratos/configuring). 3. Malformed DSN or Connection Issues: If the DSN is not in the correct format or the database is unreachable, Kratos may fail to connect and could fall back to in-memory storage, especially in development or quickstart setups [Self-hosted deployment](https://www.ory.sh/docs/self-hosted/deployment#sqlite). What to do next: - Double-check that no

DSN

environment variable is set to

memory

or another value. - Ensure you are starting Kratos with the correct config file. - Verify your DSN is correctly formatted and the database is reachable. > The knowledge sources do not mention any built-in Kratos API or CLI command to display the effective DSN at runtime, so you must verify the config file and environment variables directly. If you continue to experience issues, increase the log level to get more details about the database connection process.

If your clients are not hosted on the same domain and you want to implement a uniform login flow, you might think to use the API client (native) flow. However, the Ory documentation strongly warns against using API flows for browser-based applications (such as SPAs or server-side rendered apps), even if they are on different domains. This is because API flows do not provide the same level of CSRF and session protection as browser flows, and using them in browser contexts opens up several potential attack vectors, including login and CSRF attacks [Self-service flows](https://www.ory.sh/docs/kratos/self-service#performing-login-registration-settings--flows) [API flows](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more). Key points from the documentation: - Browser flows are recommended for browser-based clients, but require the UI and Ory to be on the same top-level domain for secure cookie handling and CSRF protection [Browser flows](https://www.ory.sh/docs/kratos/self-service#browser-flows-for-server-side-apps-nodejs-php-java-). - API flows are intended for native mobile apps, desktop apps, command-line interfaces, smart TVs, and similar clients—not for browser-based apps, regardless of domain [API flows](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more). If your clients are browser-based and on different domains, you will face limitations due to browser cookie isolation and security requirements. The documentation suggests that, in such cases, you may need to use OpenID Connect (OIDC) to federate authentication across domains, but even then, each domain will have its own session due to browser security models [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). Summary: - Do not use API flows for browser-based clients, even if they are on different domains. - For native/mobile/desktop clients, API flows are appropriate. - For browser-based clients on different domains, consider OIDC for federated login, but be aware of session isolation per domain. If you need a uniform login experience across multiple browser-based clients on different domains, you will need to architect your solution with these constraints in mind.

Yes, according to the official Ory documentation, it is a hard requirement that Ory Kratos and your UI must be hosted on the same top-level domain for browser-based flows (including login, registration, and settings). This is necessary for secure handling of cookies (sessions, CSRF protection) and to ensure that browser security models are respected. The documentation states: > Ory and your UI must be hosted on the same top level domain. You can't host Ory and your UI on separate top level domains: > > -

<http://ory.bar.com|ory.bar.com>

and

<http://app.bar.com|app.bar.com>

will work; > -

<http://ory.bar.com|ory.bar.com>

and

<http://bar.com|bar.com>

will work; > -

<http://ory.bar.com|ory.bar.com>

and

<http://not-bar.com|not-bar.com>

will not work. > > [Self-service flows](https://www.ory.sh/docs/kratos/self-service#browser-flows-for-server-side-apps-nodejs-php-java-) This requirement is repeated throughout the documentation for all browser-based flows, including login, registration, and settings [Login flow](https://www.ory.sh/docs/kratos/self-service/flows/user-login#initialize-login-flow) [Registration flow](https://www.ory.sh/docs/kratos/self-service/flows/user-registration#initialize-registration-flow) [Settings flow](https://www.ory.sh/docs/kratos/self-service/flows/user-settings#initialize-settings-flow). If you attempt to use browser-based flows across different top-level domains, cookies will not be shared, and the flows will not work as intended. For multi-domain scenarios, Ory recommends using OpenID Connect (OIDC) for federated authentication, but even then, each domain will have its own session due to browser security constraints [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). In summary: It is a hard requirement for browser-based flows that Ory and your UI are on the same top-level domain. This is not just a recommendation, but a technical and security necessity enforced by browser behavior and Ory’s security model.