|
| 1 | +import { Callout } from "nextra/components"; |
| 2 | +import { InlinePlayground } from "@/components/playground"; |
| 3 | + |
| 4 | +# Querying Data |
| 5 | + |
| 6 | +This page walks through the main ways to query data in SpiceDB. The options are listed from most preferred to least preferred, but the right choice always depends on your use case. |
| 7 | + |
| 8 | +<Callout type="important"> |
| 9 | + When invoking any of our APIs, you can send a header `X-Request-ID=somevalue` |
| 10 | + and it will be echoed back in the response, which makes correlating logs or |
| 11 | + tracing requests easy. |
| 12 | +</Callout> |
| 13 | + |
| 14 | +## CheckPermissions |
| 15 | + |
| 16 | +[`CheckPermissions`](https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.CheckPermission) is the go-to for most access checks. It’s fast, cached, and designed for high-traffic workloads. |
| 17 | + |
| 18 | +You can debug a check locally with `zed permission check resource:someresource somepermission user:someuser --explain` to see how the decision was made. |
| 19 | + |
| 20 | +When your schema uses caveats and you don't provide all the required context in the request parameters, the API will tell you that in the response that the result is "conditional" instead of simply denying or allowing, and it's up to you to inspect that result. |
| 21 | + |
| 22 | +The `subject` of the query can be a single user (e.g. `user:maria`) or a set of users (e.g. `group:engineering#member`). |
| 23 | + |
| 24 | +For read-your-writes behavior, you should pass a `consistency` parameter to the query. Use either `fully_consistent` or `at_least_as_fresh(revision)` depending on how strict you need to be. |
| 25 | + |
| 26 | +## CheckBulkPermissions |
| 27 | + |
| 28 | +[`CheckBulkPermissions`](https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.CheckBulkPermissions) is great for UI workloads where you need to check multiple permissions at once: think tables, lists, and dashboards. |
| 29 | + |
| 30 | +## LookupResources |
| 31 | + |
| 32 | +[`LookupResources`](https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.LookupResources) is a good choice when you need to find all resources of a given type that a specific subject can access. It supports pagination and works well for moderate result sizes. |
| 33 | + |
| 34 | +If you’re expecting more than ~1,000 results, this isn't ideal. At that point you'll get better performance and cost efficiency from our [Materialize] offering. |
| 35 | + |
| 36 | +[Materialize]: /authzed/concepts/authzed-materialize |
| 37 | + |
| 38 | +## LookupSubjects |
| 39 | + |
| 40 | +[`LookupSubjects`](https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.LookupSubjects) returns all subjects that have access to a specific resource. It’s handy, but it does not support pagination. |
| 41 | + |
| 42 | +Same guidance applies as above: if you’re going to cross the ~1,000-result mark, you’ll want Materialize instead. |
| 43 | + |
| 44 | +## ReadRelationships |
| 45 | + |
| 46 | +[`ReadRelationships`](https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.ReadRelationships) should be your last resort. It's slower, it doesn't populate or use the permissions cache, and it won't evaluate caveats. Use it only when you truly need raw relationship data and none of the higher-level APIs fit the job. |
0 commit comments