@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/fga/schema-management.mdx

@@ -1,224 +0,0 @@
----
-title: Schema Management
-description: >-
-  Learn how to test, debug, and safely apply changes to your authorization
-  schema and setup a GitOps workflow to automatically validate and apply changes
-  to production.
-originalPath: .tmp-workos-clone/packages/docs/content/fga/schema-management.mdx
----
-
-## Overview
-
-Designing a schema that meets your requirements and using it in production for the first time is only the beginning of your fine-grained authorization journey. As your product's authorization requirements change, you will need to evolve your schema to meet those requirements.
-
-To do this safely, you need a process in place to test, debug, and safely apply changes to your schema in production. In case of bugs, you also need the ability to roll back to a previous (working) schema if needed.
-
-This guide will explain how to use the [FGA Dashboard](https://fga.workos.com) and [WorkOS CLI](https://github.com/workos/workos-cli) to test and debug your schema. We will use the CLI and the [CLI GitHub Action](https://github.com/workos/cli-action) to setup a GitOps workflow that automatically tests and applies changes to your schema as part of your software development life cycle (SDLC).
-
-## Before getting started
-
-To get the most out of this guide, you'll need:
-
-- A [WorkOS account](https://dashboard.workos.com/)
-- Your WorkOS [API Key](/glossary/api-key)
-- The [WorkOS CLI](/fga/quick-start/1-install-the-workos-cli)
-
----
-
-## Test Your Schema
-
-Let's create a shell script that uses the WorkOS CLI to test the example schema below.
-
-> Note: we've decided to prefix permissions in our authorization model with `can_` (`can_invite_users`) to imply an action. This is not a required convention, so feel free to use relation names that suit your application.
-
-```fga title="schema.txt"
-version 0.3
-
-type user
-
-type organization
-    relation role_admin [user]
-    relation role_member [user]
-    relation can_invite_users []
-    relation can_remove_users []
-    relation can_view_users []
-
-    inherit role_member if
-        relation role_admin
-
-    inherit can_invite_users if
-        relation role_admin
-
-    inherit can_remove_users if
-        relation role_admin
-
-    inherit can_view_users if
-        relation role_member
-
-```
-
-First, apply the schema
-
-```shell title="Apply the example schema"
-workos fga schema apply schema.txt
-```
-
-Next, use the `fga warrant create` command to setup some warrants.
-
-```shell title="Setup test data"
-workos fga warrant create user:acme_admin role_admin organization:org_acme
-workos fga warrant create user:acme_member role_member organization:org_acme
-```
-
-Then use the `fga check` command with the `--assert` flag to assert that a permission check returns the expected result.
-
-```shell title="Make assertions"
-workos fga check user:acme_admin can_invite_users organization:org_acme --assert true
-workos fga check user:acme_admin can_remove_users organization:org_acme --assert true
-workos fga check user:acme_admin can_view_users organization:org_acme --assert true
-
-workos fga check user:acme_member can_invite_users organization:org_acme --assert false
-workos fga check user:acme_member can_remove_users organization:org_acme --assert false
-workos fga check user:acme_member can_view_users organization:org_acme --assert true
-```
-
-Finally, use the `fga resource delete` command to clean up the test data. This makes it easy to re-run tests with a clean environment in the future.
-
-```shell title="Clean up test data"
-workos fga resource delete user:acme_admin
-workos fga resource delete user:acme_member
-workos fga resource delete organization:org_acme
-```
-
----
-
-## Debug Your Schema
-
-The simplest way to understand (debug) why your schema is (or is not) answering a permission check as you expect it to is via the [Check page](https://fga.workos.com/check) or using the `--debug` flag via the CLI.
-
-### Using the FGA Dashboard
-
-To debug a permission check from the FGA dashboard, navigate to the [Check page](https://fga.workos.com/check). Enter valid arguments for the permission check you want to debug and click `Check Access`. The page will display the result of the permission check and a tree visualizing all of the paths in the authorization graph that were explored to reach the result.
-
-### Using the CLI
-
-To debug a permission check using the CLI, use the `fga check` command with the `--debug` flag:
-
-```shell title="Debug a permission check"
-workos fga check user:james can_approve_purchase purchase:pur_123 --debug
-```
-
-Permission checks that use the `--debug` flag will output the check result and a tree visualizing all of the paths in the authorization graph that were explored to reach the result.
-
-> Note: running the `fga check` command with the `--debug` flag will execute the check without any caching enabled.
-
-#### Tests
-
-The CLI provides a streamlined way to run multiple tests against your schema using a single `workos fga test command`. The `test` command will set up warrants, perform checks, and handle teardown.
-
-It also supports running multiple test files from a directory, allowing you to organize tests in a structure that fits your application.
-
-```yaml title="org-roles.test.yaml"
-setup:
-  warrants:
-    - subject: user:acme_admin
-      relation: role_admin
-      resource: organization:org_acme
-    - subject: user:acme_member
-      relation: role_member
-      resource: organization:org_acme
-
-tests:
-  - name: acme_admin can invite users
-    check:
-      subject: user:acme_admin
-      relation: can_invite_users
-      resource: organization:org_acme
-    expect: true
-
-  - name: acme_admin can remove users
-    check:
-      subject: user:acme_admin
-      relation: can_remove_users
-      resource: organization:org_acme
-    expect: true
-
-  - name: acme_admin can view users
-    check:
-      subject: user:acme_admin
-      relation: can_view_users
-      resource: organization:org_acme
-    expect: true
-
-  - name: acme_member cannot invite users
-    check:
-      subject: user:acme_member
-      relation: can_invite_users
-      resource: organization:org_acme
-    expect: false
-
-  - name: acme_member cannot remove users
-    check:
-      subject: user:acme_member
-      relation: can_remove_users
-      resource: organization:org_acme
-    expect: false
-
-  - name: acme_member can view users
-    check:
-      subject: user:acme_member
-      relation: can_view_users
-      resource: organization:org_acme
-    expect: true
-
-teardown:
-  resources:
-    - user:acme_admin
-    - user:acme_member
-    - organization:org_acme
-```
-
-To run the tests defined in the `schema.test.yaml` file, use the following command:
-
-```shell title="Run tests"
-workos fga test org-roles.test.yaml
-```
-
-> The teardown section is optional and used for cleaning up specific data (resources or warrants). If you want to automatically cleanup **all resources and warrants** created during the test, you can also use the `--cleanup` flag when running the `workos fga test` command.
-
----
-
-## GitOps Workflow
-
-Now that we have a script to test that our schema works as we expect, let's setup a GitHub Action to automatically test changes to the schema and apply the schema if all of the tests pass.
-
-```yaml title=".github/workflows/fga.yaml"
-name: Test FGA Schema
-
-on:
-  push:
-    branches: [main]
-
-jobs:
-  ci:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Install WorkOS CLI
-        uses: workos/cli-action@v1
-        with:
-          version: latest
-      - name: Test Schema
-        run: |
-          workos fga schema apply schema.txt
-          workos fga test tests/org-roles.test.yaml
-        env:
-          WORKOS_ACTIVE_ENVIRONMENT: staging
-          WORKOS_ENVIRONMENTS_HEADLESS_API_KEY: <your_workos_staging_api_key>
-      - name: Apply Schema to Production
-        if: github.ref == 'main' && github.event_name == 'push'
-        run: |
-          workos fga schema apply schema.txt
-        env:
-          WORKOS_ACTIVE_ENVIRONMENT: production
-          WORKOS_ENVIRONMENTS_HEADLESS_API_KEY: <your_workos_production_api_key>
-```

package/.docs/organized/docs/fga/schema.mdx

@@ -1,388 +0,0 @@
----
-title: Schema
-description: >-
-  Define authorization logic independently from application code using a
-  domain-specific language (DSL).
-showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/fga/schema.mdx
----
-
-## Overview
-
-A schema is the core structure of an authorization model in FGA. It defines the types of resources, the relations between them, and the policies that govern access.
-
-A schema can be represented in two formats:
-
-- **JSON** – Accepted by [Schema API](/reference/fga/schema) endpoints when using `Content-Type: application/json`.
-- **FGA Schema Language** – A more developer-friendly domain-specific language (DSL) that is applied via the `apply` command with the CLI or on the [FGA Dashboard](https://fga.workos.com/schema).
-
-Schemas allow you to manage authorization logic independently from application logic. They can be versioned, stored in Git, and applied via the CLI:
-
-```shell
-workos fga schema apply ./schema.txt
-```
-
-Once applied, changes take effect immediately, meaning any updates to authorization logic will instantly reflect in subsequent permission checks and queries.
-
-FGA Schema Language transpiles into JSON format so that you can write your authorization model in a more readable and maintainable way, but still use JSON for API calls if you prefer.
-
-## JSON vs Schema Language
-
-The JSON representation of a schema is the raw format that FGA uses to define resource types, relations, and inheritance rules. However, it can be verbose and difficult to read - especially for complex authorization models.
-
-Consider the following examples:
-
-### JSON Representation
-
-```json
-{
-  "resource_types": [
-    {
-      "type": "user",
-      "relations": {
-        "manager": {
-          "allowed_types": ["user"]
-        }
-      }
-    },
-    {
-      "type": "store",
-      "relations": {
-        "owner": {
-          "allowed_types": ["user"]
-        },
-        "editor": {
-          "allowed_types": ["user"],
-          "inherit_if": "owner"
-        },
-        "viewer": {
-          "allowed_types": ["user"],
-          "inherit_if": "editor"
-        }
-      }
-    },
-    {
-      "type": "item",
-      "relations": {
-        "owner": {
-          "allowed_types": ["user"]
-          "inherit_if": "owner",
-          "of_type": "store",
-          "with_relation": "parent"
-        },
-        "editor": {
-          "allowed_types": ["user"],
-          "inherit_if": "any_of",
-          "rules": [
-            {
-              "inherit_if": "owner"
-            },
-            {
-              "inherit_if": "editor",
-              "of_type": "store",
-              "with_relation": "parent"
-            },
-            {
-              "inherit_if": "manager",
-              "of_type": "user",
-              "with_relation": "owner"
-            }
-          ]
-        },
-        "viewer": {
-          "allowed_types": ["user"],
-          "inherit_if": "editor"
-        },
-        "parent": {
-          "allowed_types": ["store"]
-        }
-      }
-    }
-  ]
-}
-```
-
-### Schema Language Representation
-
-```fga
-version 0.3
-
-type user
-    relation manager [user]
-
-type store
-    relation owner [user]
-
-    relation viewer [user]
-    inherit viewer if
-        relation editor // editors are also viewers
-
-    relation editor [user]
-    inherit editor if
-        relation owner
-
-type item
-    // An item can have a parent store
-    relation parent [store]
-
-    relation owner [user]
-    inherit owner if
-        relation owner on parent [store]
-
-    relation editor [user]
-    inherit editor if
-        any_of
-            relation owner
-            relation editor on parent [store]
-            relation manager on owner [user]
-
-    relation viewer [user]
-    inherit viewer if
-        relation editor
-```
-
-The FGA schema language representation is more concise, easier to read, and supports comments. These features make it simpler to define and manage complex authorization models in a more developer-friendly format.
-
-## Schema Syntax
-
-### Version
-
-Each schema must start with a `version` declaration. This version declaration dictates the version of the schema language the transpiler will use to convert the schema into its JSON representation. As we add support for new features and functionality to the schema language, we will release new versions of it. Versioning the language in this way allows us to ensure backwards compatibility as we roll out these enhancements. See a full changelog of schema versions [here](/fga/schema/schema-changelog).
-
-<CodeBlock file="schema-version" />
-
-### Comments
-
-Comments are prefixed with `//`. Comments are ignored by the transpiler.
-
-<CodeBlock file="schema-comment" />
-
-### Resource Types
-
-Resource types are the basic building blocks of an authorization model in FGA. Each resource type defines a set of relationships that can exist on a specific type of resource (e.g. store, item, etc). These relationships can be assigned to other resources (e.g. user) known as subjects.
-
-Resource types are an incredibly flexible way to define authorization models, allowing you to express complex hierarchical and inherited relationships. They can be created directly in the [FGA dashboard](https://fga.workos.com/schema), via the [Resource Types API](/reference/fga/resource-type/create) or by applying the schema with the CLI.
-
-Let's explore the various attributes of resource types by creating a schema-based authorization model for a simple e-commerce application that has three resource types: users, stores, and items.
-
-First, define a resource type using the `type` keyword. Each resource type must have a unique string as its type. Let's start defining the resource types for our e-commerce application:
-
-<CodeBlock file="schema-resource-types" />
-
-### Relations
-
-With the basic definitions above, we've started building an authorization model for our application that will allow us to create fine grained access control rules for stores, items, and users, helping us answer questions like:
-
-```shell
-Does [user:1] have the ability to [edit] [item:x]?
-is [user:1] the [owner] of [store:3]?
-```
-
-In order to create access rules using our resource types, we first need to define the relationships available on a resource of that type. For example, if we want to specify that `[user:A] is an [owner] of [store:S]`, we must add an `owner` relation to the `store` resource type.
-
-By default, a subject can only have a relation on a resource explicitly. This means the relation must be _explicitly_ granted via a [warrant](/fga/warrants).
-
-Let's add some relations to our resource types.
-
-In our application, a store can have `owners`, `editors`, and `viewers`. `owners` and `editors` have more privileged access (like being able to modify details about a store) than `viewers` (who have read-only access).
-
-An item can have the same three relations as a store _plus_ a fourth relation called `parent`. This is because a store can be the `parent` of an item, meaning the item belongs to that store. We'll use this relation later to implement inherited relations on items.
-
-Lastly, our `user` resource type is relatively simple and has one relation: `manager`. This is because a user can be the `manager` of another user. We'll use this relation later to enable inherited relations based on user hierarchies.
-
-Let's add these relations to our resource types:
-
-<CodeBlock file="schema-relations" />
-
-With these resource types, we can now create authorization rules that specify exactly which users are `owners`, `editors`, and `viewers` of each store or item. We can also assign stores as `parents` of items, and users as `managers` of other users.
-
-Use brackets [] in the schema language after defining a relation to enforce which type(s) of subjects can be assigned the relation.
-
-Use empty type restrictions to define computed relationships with no direct subjects. This is useful for defining a relation that cannot be assigned directly to a subject but is used to make an authorization check from your application.
-
-> Version `0.1` of the schema language does not support type safety on relations.
-
-### Inheritance Rules
-
-While only using explicitly assigned relations to build your authorization model can be powerful, creating warrants for each and every relationship in an application can become tedious or infeasible for larger, more complex use cases. That's why relations can define rules under which they can be inherited (e.g. `a user is an editor of a store if they're an owner of that store`).
-
-There are two ways in which relations can be inherited:
-
-- Relation Inheritance
-- Resource Inheritance
-
-#### Relation Inheritance
-
-In practice, it's common for relations to have overlap (e.g. an `owner` has the same privileges as an `editor` + additional privileges). For example, in many applications a user with write privileges inherits read privileges too.
-
-In our example application, an `owner` will inherit both the `editor` and the `viewer` relations, and an `editor` will inherit the `viewer` relation. Instead of having to explicitly assign each of the `owner`, `editor`, and `viewer` relations to a user who is an `owner`, resource types allow you to specify an inheritance hierarchy (e.g. the `editor` relation is inherited if the user is an `owner`) using the `inherit_if` property.
-
-Let's add `inherit <relation> if` rules to our `store` and `item` resource types specifying that:
-
-- `owners` are also `editors`
-- `editors` are also `viewers`
-
-<CodeBlock file="schema-relation-inheritance" />
-
-With our `inherit <relation> if` rules in place, we can simply grant a user the `editor` relation and they will implicitly inherit the `viewer` relation. `inherit` rules also work recursively on other inherited relations, so assigning a user the `owner` relation will implicitly grant that user _both_ the `editor` and `viewer` relations. This is because `owner` will inherit `editor` and `editor` will in turn inherit `viewer`.
-
-This will simplify our access checks and cut down on the number of warrants we need to create for each user.
-
-#### Resource Inheritance
-
-In many applications, resources themselves have a hierarchy (e.g. a document belongs to a folder, a user belongs to a team, a team belongs to an organization, etc.) and the access rules for these resources follow that hierarchy (e.g. the owner of a folder is the owner of any document in that folder).
-
-Using the following two rules:
-
-```txt
-inherit <relation> if
-```
-
-```txt
-relation <resource_type.relation> on <relation> [<resource_type>]
-```
-
-We can specify that a relation can be inherited when a user has a particular relation (`<resource_type.relation>`) on another resource (`<resource_type>`) that has a particular relation (`<relation>`) on the resource we are checking access to.
-
-For example, a user is an `editor` of a document if they are an `editor` of a `folder` that is the document's `parent`. In our example app, let's define the following three resource inheritance rules:
-
-1. A user is an `owner` of an item if that user is an `owner` of a `store` that is the item's `parent`.
-2. A user is an `editor` of an item if that user is an `editor` of a `store` that is the item's `parent`.
-3. A user is an `editor` of an item if that user is the `manager` of the `user` that is the item's `owner`.
-
-> **NOTE:** Some of the relations below will be [composing multiple inheritance rules together using logical operators](/fga/schema/schema-syntax/logical-operators). We'll cover this in detail later.
-
-<CodeBlock file="schema-resource-inheritance" />
-
-These rules make it easy to define inheritance rules for complex relationships between resources so we don't have to create a large number of explicit warrants. Without them, we'd need to create a warrant for every item &harr; store &harr; user relationship in our application. This could easily be thousands, if not hundreds of thousands of rules.
-
-### Logical Operators
-
-With both the two types of relation inheritance rules in our toolkit, we can create authorization models for a majority of use cases, but there are still some scenarios that require a combination of these inheritance rules (e.g. a user is an `editor` of an item if they are an `owner` of that item **OR** they are the `manager` of another user who is an `editor` of that item).
-
-To design authorization models that cover such scenarios, relations can compose multiple inheritance rules using _logical operators_ to form more complex conditions.
-
-The three supported logical operations are `any_of`, `all_of`, and `none_of`.
-
-#### any_of
-
-The `any_of` operation allows you to specify that a relation be inherited if _at least one of_ the rules in the set is satisfied. In other words, it works like the logical _OR_ operation.
-
-The following resource type specifies an `editor-or-viewer` relation that is inherited if the user is an `editor` **OR** if the user is a `viewer`:
-
-<CodeBlock file="schema-any-of" />
-
-#### all_of
-
-The `all_of` rule type allows you to specify that a relation be inherited if _all of_ the rules in the set are satisfied. In other words, it works like the logical _AND_ operation.
-
-The following resource type specifies an `editor-and-viewer` relation that is implicitly granted if the user is an `editor` **AND** the user is a `viewer`:
-
-<CodeBlock file="schema-all-of" />
-
-#### none_of
-
-The `none_of` rule type allows you to specify that a relation be inherited if _none of_ the rules in the set are satisfied. In other words, it works like the logical _NOR_ operation.
-
-The following resource type specifies a `not-editor-and-not-viewer` relation that is implicitly granted if the user is _not_ an `editor` **AND** the user is _not_ a `viewer`:
-
-<CodeBlock file="schema-none-of" />
-
-### Policies
-
-Policies are a way to define custom logic that can be used in your schema. They allow you to create complex rules that go beyond simple relation inheritance. Policies can be defined using the `policy` keyword and can include parameters, expressions, and logical conditions.
-
-<CodeBlock file="schema-policies" />
-
-Read more about policies in the [Policies documentation](/fga/policies).
-
-### Group Warrants
-
-Define type restrictions on [group warrants](/fga/warrants/group-warrants) by joining the type and expected relation with a `#`. For example, `relation editor [group#member]` means that the `editor` relation can be assigned to warrants where `group` is the subject type and `member` is the subject relation.
-
-Group warrants are a special type of warrant that allow you to define exceptions to schema relationships at runtime. See the [Group Warrant documentation](/fga/warrants/group-warrants) for more details.
-
-<CodeBlock file="schema-group-warrants" />
-
-If your relation type defines a resource type and no group warrant types, it will default to allow all group warrants.
-
-For example:
-
-```js
-// Allows subject_type == "group" and subject_relation == null | <any_value>
-relation editor [group]
-
-// Allows subject_type == "group" and subject_relation == "member"
-relation editor [group#member]
-
-// Allows subject_type == "group" and subject_relation == "member" | "owner"
-relation editor [group#member, group#ownwer]
-
-// Allows subject_type == "group" and subject_relation == null | "member"
-relation editor [group, group#member]
-```
-
-## Converting Schema Language to JSON
-
-You can convert the FGA schema language to JSON using the `workos fga schema convert` command. This command transpiles the schema language into its JSON representation, which can then be used with the FGA API.
-
-```shell
-workos fga schema convert schema.txt --to json --output raw > schema.json
-```
-
-## Schema Changelog
-
-### v0.3
-
-- Add support for policy in the schema
-
-```fga
-version 0.3
-
-type user
-
-type group
-    relation member [user]
-
-type asset
-    relation access_diagnostics []
-    relation service_manager [group]
-
-    inherit access_diagnostics if
-        all_of
-          relation member on service_manager [group]
-          policy is_in_geo_fence
-
-policy is_in_geo_fence(user_location map, geofence map) {
-    user_location.lat >= geofence.min_lat &&
-    user_location.lat <= geofence.max_lat &&
-    user_location.lon >= geofence.min_lon &&
-    user_location.lon <= geofence.max_lon
-}
-
-```
-
-### v0.2
-
-- Add support for resource-type relation type safety
-- Add support for group warrant types
-
-```fga
-version 0.2
-
-type report
-    relation parent [organization, organization#member]
-    relation owner [user]
-    relation editor [user]
-```
-
-### v0.1
-
-- Initial implementation of the schema language
-- Supported features:
-  - Transpiler version
-  - Resource types
-  - Relations
-  - Inheritance rules
-  - Resource inheritance
-  - Logical operators

package/.docs/organized/docs/fga/warrant-tokens.mdx

@@ -1,44 +0,0 @@
----
-title: Warrant Tokens
-description: >-
-  Configure whether you favor performance or consistency on a per request basis
-  depending on your application's consistency requirements.
-showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/fga/warrant-tokens.mdx
----
-
-## Overview
-
-FGA is a distributed service deployed to multiple cloud regions. All traffic to the FGA API flows through a single endpoint (`api.workos.com/fga`). To ensure reliability, data is replicated to multiple regions behind the scenes. To maximize performance, FGA is an _eventually consistent_ service by default.
-
-In order to balance performance and consistency, FGA supports a _bounded staleness protocol_ similar to Google Zanzibar's _Zookie_ protocol. This allows client applications to specify when they prefer the fastest results (to minimize latency added by authorization checks) and when they prefer immediately consistent results (to ensure recent changes to permissions are reflected for a particular check or query).
-
-FGA generates an opaque token (known as a _Warrant Token_) for all warrant _write_ operations (i.e. creating or deleting warrants). Each Warrant Token uniquely identifies a warrant write operation. All warrant write operations return a Warrant Token in the response body.
-
-```shell
-{
-  "warrant_token": "MjM0fDM0MzQyM3wyMTM0MzM0MzY0NQ=="
-}
-```
-
-## `Warrant-Token` Header
-
-Unlike traditional eventually-consistent distributed systems, FGA allows clients to specify their desired consistency level via Warrant Tokens. Clients can pass a previously generated Warrant Token via the `Warrant-Token` header on check, query, and list warrants requests to instruct the server to process the request using data _no older_ than the write operation identified by the specified Warrant Token. This allows clients to ensure that a particular check, query, or list warrants request has the data necessary to give the most up-to-date result as dictated by the application's authorization requirements.
-
-### `latest`
-
-In some cases, a client may need an up-to-date result but may not have an accompanying Warrant Token to use for the request. In this scenario, the client can pass the special value `latest` in the `Warrant-Token` header to instruct FGA to use the most up-to-date data:
-
-```shell
-'Warrant-Token: latest'
-```
-
-Note that using the `latest` token effectively instructs FGA to bypass all caches in favor of hitting the database for the most up-to-date result. Therefore, it can incur additional performance overhead, so it's recommended to only use `latest` sparingly. Instead, opt to use server-provided Warrant Tokens or no token at all (the default consistency) to maximize performance in most cases.
-
-## Storing Warrant Tokens
-
-In practice, clients can store Warrant Tokens in their system on a _per-subject_ basis, passing in the stored token to each read request for that subject to achieve optimal performance. For example, if creating a new warrant (e.g. `user:x is an editor of report:y`) generates a Warrant Token with value `45f87sdf=`, the client can store that token their db along for subject `user:x`. Subsequent checks or queries for `user:x` can then include that stored Warrant Token for the optimal balance of performance and consistency.
-
-## Default consistency
-
-Passing a Warrant Token on check, query, and list warrants requests is optional. If a Warrant Token is not provided, FGA uses a default staleness window to fulfill check and query requests. This window is cache-optimized and is the recommended approach for the 90-95% of read requests that can tolerate short periods (on the order of seconds) of inconsistent results.