To avoid duplicate relation-tuples in Ory Keto (and Ory Permissions), you should be aware that the system is designed to treat relation-tuples as unique based on the combination of namespace, object, relation, and subject. When you attempt to create a relation-tuple that already exists, Keto will not create a duplicate; it will simply ignore the request or update the existing tuple, depending on the API or CLI command used. Here are some practical steps to avoid duplicates: 1. Check Before Creating: Use the list or get API/CLI command to check if a relation-tuple already exists before creating it. For example, you can use:

keto relation-tuple get --namespace <namespace> --object <object> --relation <relation> --subject-id <subject>

If the tuple exists, you can skip creation. 2. Idempotent Creation: The create operation is idempotent—creating the same tuple multiple times does not result in duplicates. This is reflected in the CLI and API design, so you do not need to worry about accidental duplication when using the standard creation commands. 3. Batch Operations: When importing or syncing large sets of relation-tuples, ensure your data source does not contain duplicates, or rely on Keto’s idempotency to handle them gracefully. 4. Use the CLI/SDKs: Using the official Ory CLI or SDKs helps prevent issues, as they follow the correct API semantics and will not create duplicates if the tuple already exists. The documentation recommends using these tools to avoid low-level mistakes that could lead to unexpected behavior, especially when interacting with the API directly [keto relation-tuple create](https://www.ory.sh/docs/keto/guides/migrating-legacy-policies). 5. Be Careful with Delete Operations: When deleting, ensure your queries are specific to avoid unintended mass deletions, but this does not directly relate to duplication—just a best practice for tuple management [Sending DELETE request with non existed ID deletes ALL relation tuples on ORY Cloud](https://github.com/ory/network/issues/230). In summary, Ory Keto’s design prevents duplicate relation-tuples by treating each tuple as unique based on its fields, and the create operation is idempotent. You do not need to implement additional deduplication logic when using the standard APIs or CLI commands. If you are building custom integrations, always check for existence before creating new tuples to be extra cautious. If you need more advanced deduplication or conflict resolution, you may need to implement that logic in your application layer, but for most use cases, Keto’s built-in behavior is sufficient.

e

The Ory Keto (and Ory Permissions) DELETE endpoint for relation-tuples (

DELETE /admin/relation-tuples

) returns a 204 No Content status code regardless of whether any tuples were actually deleted. This is by design and follows standard REST API conventions: a 204 response simply means the request was processed successfully, not that any resources were actually deleted. If the query matches no tuples, the response is still 204, with no indication of whether anything was deleted or not [Ory API Reference - deleteRelationships](https://www.ory.sh/docs/reference/api) [Ory Keto API Reference - deleteRelationships](https://www.ory.sh/docs/keto/reference/rest-api). How to verify what was deleted: - The API does not return information about what was deleted in the response to a DELETE request. - To verify what will be deleted, you should first use the corresponding GET endpoint with the same query parameters. This allows you to see which relation-tuples match your query before you delete them. - After deletion, you can use the GET endpoint again to confirm that the tuples are no longer present. This approach is also recommended by Ory team members in response to user questions about accidental mass deletions: "the DELETE endpoint is symmetrical to GET, which means that you can already check which tuples will be deleted by passing the same request to GET. In your case, you would have gotten all tuples" [Github Issue: Sending DELETE request with non existed ID deletes ALL relation tuples on ORY Cloud](https://github.com/ory/network/issues/230). Summary: - 204 means the request was processed, not that anything was deleted. - Use GET before and after DELETE to verify what will be (or was) deleted. - The API does not provide a count or list of deleted items in the DELETE response.

To list active namespaces in Ory Keto or Ory Permissions, you can use the REST API endpoint:

GET /namespaces

This endpoint returns all namespaces currently configured in your system. The response will include an array of namespace objects, each with its name. No authentication is required for this operation in Keto, but Ory Network may require authentication. Example response:

json {   "namespaces": [     { "name": "files" },     { "name": "groups" }     // ...   ] }

You can also use the Ory CLI to fetch the permission configuration, which includes namespaces:

ory get permission-config --project <project-id> --format json

This will output the namespaces defined in your project [ory get permission-config](https://www.ory.sh/docs/cli/ory-get-permission-config). For more details, see the [Keto API Reference - listRelationshipNamespaces](https://www.ory.sh/docs/keto/reference/rest-api) and [Ory API Reference - listRelationshipNamespaces](https://www.ory.sh/docs/reference/api).

Based on the available knowledge sources, Ory Keto allows you to validate multiple namespace definition files at once using the CLI command:

keto namespace validate <namespace.yml> [<namespace2.yml> ...]

This means you can split your namespace definitions into multiple files and validate them together, rather than having to put everything into one large file. The documentation specifically shows that you can pass several files to the validation command, which suggests support for managing namespaces in multiple files during development and validation workflows [Validate namespace definitions](https://www.ory.sh/docs/keto/cli/keto-namespace-validate). However, the knowledge sources do not explicitly state whether you can load or apply multiple namespace files directly to a running Keto instance for production use, or if you need to merge them before applying. For validation and development, multiple files are supported; for deployment, you may need to consult further documentation or test merging as part of your workflow. In summary: - You can validate multiple namespace files at once. - It is not explicitly documented whether you can load multiple files directly for production; you may need to merge them before applying.

The knowledge sources do not explicitly describe a built-in tool or command in Ory Keto for merging multiple namespace definition files into a single file for production use. However, they do show that you can validate multiple namespace files at once using the CLI (e.g., 

keto namespace validate <namespace1.yml> <namespace2.yml>

), which is helpful during development [keto namespace validate](https://www.ory.sh/docs/keto/cli/keto-namespace-validate). For production deployment, the documentation does not specify whether Keto can directly load multiple namespace files, or if you must manually combine them into one file before applying them to your instance. Therefore, if you need a single file for production, you would need to manually merge your YAML files using standard YAML tools or by concatenating the contents, ensuring the resulting file is valid. In summary: - There is no documented Keto-specific tool for merging namespace files. - You may need to manually combine your namespace definitions into one file for production deployment. - Always validate the merged file using

keto namespace validate

before applying it. If you need more detailed guidance, the knowledge sources do not provide further information on this topic.

The knowledge sources confirm that Ory Keto supports namespace definitions in both YAML and JSON formats. You can validate multiple namespace files at once using the CLI, regardless of whether they are YAML or JSON:

keto namespace validate <namespace1.json> <namespace2.json>

However, for production deployment, the documentation does not specify whether you can load multiple JSON (or YAML) namespace files directly, or if you must merge them into a single file. If merging is required, you would need to manually combine the JSON files into one valid JSON array or object, depending on the expected structure, and then validate the merged file using the CLI [keto namespace validate](https://www.ory.sh/docs/keto/cli/keto-namespace-validate). Summary: - You can validate multiple JSON namespace files at once. - For production, you may need to merge them manually, as the documentation does not state that multiple files can be loaded directly. - Always validate the merged file before applying it. If you need more details on merging JSON files for Keto, the knowledge sources do not provide further specifics.

Ory Keto supports loading configuration from multiple files by specifying the --config (or -c) flag multiple times when starting the server. The files are merged in the order provided, with later files overwriting values from earlier ones. For example:

keto serve --config /etc/config/keto/base.yaml --config /etc/config/keto/override.yaml

This approach works for the main Keto configuration. However, the knowledge sources do not explicitly state that this mechanism applies to namespace definition files. For namespaces, you may need to merge them manually into a single file before applying, as there is no documentation confirming direct support for loading multiple namespace files at runtime [Configuration](https://www.ory.sh/docs/ecosystem/configuring). In summary: - Multiple config files are supported for the main Keto configuration using repeated --config flags. - For namespace definitions, manual merging may be required, as multi-file support at runtime is not documented.

The command

keto migrate up --yes --config /etc/config/keto/keto-config.yaml

does the following: - keto migrate up: Runs the database schema migrations to bring your Ory Keto database up to the latest version. This is necessary when setting up a new SQL database or upgrading Keto from version v0.7.x and later. - --yes: Automatically confirms all prompts, so the migration proceeds without requiring interactive user input. - --config /etc/config/keto/keto-config.yaml: Specifies the path to the Keto configuration file to use for this operation. Important: It is recommended to run this command close to your SQL instance (e.g., on the same subnet) to reduce the risk of failure and decrease migration time. Always back up your database before running migrations on an existing database [keto migrate up](https://www.ory.sh/docs/keto/cli/keto-migrate-up). This command does not affect namespaces; it only migrates the main database schema [keto migrate](https://www.ory.sh/docs/keto/cli/keto-migrate).