Based on the knowledge sources, the

batchCheckPermission

method in the Ory Go client requires an API key because it's part of the authenticated operations in the Ory API. According to the documentation, when using the Ory Network (the commercial offering), operations on the permission API require authentication: > To perform this operation, you must be authenticated by means of one of the following methods: > * oryAccessToken [Ory API Reference](https://www.ory.sh/docs/reference/api) This is demonstrated in the Go SDK examples where API calls are made with an authenticated context:

go var oryAuthedContext = context.WithValue(context.Background(), ory.ContextAccessToken, os.Getenv("ORY_API_KEY"))

[Ory Permissions Go SDK](https://www.ory.sh/docs/keto/sdk/go) It's worth noting that for self-hosted Keto (the open-source version), the documentation indicates that authentication might not be required:

go readClient.PermissionApi.CheckPermission(context.Background())

[Keto Self-hosted Go](https://www.ory.sh/docs/keto/self-hosted/go) The difference in authentication requirements between Ory Network and self-hosted Keto is because Ory Network is a multi-tenant service where API keys are used to identify and authorize your specific project, while in self-hosted environments, you control your own authentication mechanisms.

The

max-depth

parameter in the

batchCheckPermission

method (and other permission check methods) controls the maximum depth of the search tree when resolving permissions in Ory Keto/Permissions. According to the documentation, this parameter is important for several reasons: 1. Performance control: It keeps request latency within acceptable bounds by limiting how deep the permission system will traverse relationship hierarchies [Keto API Reference](https://www.ory.sh/docs/keto/reference/rest-api). 2. Resource usage: It limits the resource usage per request, which is important for system stability [Keto API Overview](https://www.ory.sh/docs/keto/concepts/api-overview). 3. Abstraction level: It allows you to control the level of detail in permission resolution. For example, you might only want to resolve direct permissions (depth 1) or include indirect permissions through group memberships (depth 2-3) [Expand API Guide](https://www.ory.sh/docs/keto/guides/expand-api-display-who-has-access#maximum-tree-depth). The documentation provides a practical example of how different depths work: - depth 1: directly granted access - depth 2: indirectly granted access through ownership - depth 3: indirectly granted access through ownership of the parent If you specify a value less than 1 or greater than the global max-depth configuration, the system will use the global max-depth instead as a safeguard. This parameter is available in all permission check endpoints, including the batch version, and can be passed as a query parameter in REST API calls or as an option in SDK methods.

Based on the knowledge sources provided, there is no explicit information about the default value for the

max-depth

parameter if left unspecified in permission check operations. The documentation mentions that: > If the value is less than 1 or greater than the global max-depth then the global max-depth will be used instead. [Keto Reference Proto API](https://www.ory.sh/docs/keto/reference/proto-api#oryketorelation_tuplesv1alpha2check_serviceproto) This suggests that there is a global max-depth configuration setting that serves as a fallback, but the specific default value is not mentioned in the provided knowledge sources. When using the parameter, you can specify it in various ways: - As a query parameter in REST API calls:

max-depth=10

- As a command-line flag in CLI commands:

-d, --max-depth int32

- As a parameter in SDK method calls If you need to know the exact default value, you might want to: 1. Check the Ory Keto configuration documentation 2. Test the API with and without the parameter to observe the behavior 3. Contact Ory support for definitive information