authzed/zed

Official command-line tool for managing SpiceDB

zed

A command-line client for managing SpiceDB.

zed features include:

• Context switching that stores credentials securely in your OS keychain
• Check, Expand, Lookup Resources, Lookup Subjects commands for Permissions
• Create, Read, Touch, Delete, Bulk-Delete commands for Relationships
• Read, Write, Validate, Import, Copy commands for Schemas
• Experimental Backup and Restore commands

Have questions? Ask in our Discord.

Looking to contribute? See CONTRIBUTING.md.

You can find issues by priority: Urgent, High, Medium, Low, Maybe. There are also good first issues.

Getting Started

Installing the binary

Binary releases are available for Linux, macOS, and Windows on AMD64 and ARM64 architectures.

Homebrew users for both macOS and Linux can install the latest binary releases of zed using the official tap:

brew install authzed/tap/zed

Debian-based Linux users can install zed packages by adding a new APT source:

sudo apt update && sudo apt install -y curl ca-certificates gpg
curl https://apt.fury.io/authzed/gpg.key | sudo apt-key add -
sudo sh -c 'echo "deb https://apt.fury.io/authzed/ * *" > /etc/apt/sources.list.d/fury.list'
sudo apt update && sudo apt install -y zed

RPM-based Linux users can install zed packages by adding a new YUM repository:

sudo cat << EOF >> /etc/yum.repos.d/Authzed-Fury.repo
[authzed-fury]
name=AuthZed Fury Repository
baseurl=https://yum.fury.io/authzed/
enabled=1
gpgcheck=0
EOF
sudo dnf install -y zed

Creating a context

Contexts store connection credentials for accessing SpiceDB clusters securely in the OS keychain. Before performing most commands, a context must be set. Alternatively, you can provide context values via environment variables which will override the existing context for that execution.

The zed context subcommand has operations for setting the current, creating, listing, deleting contexts:

zed context set prod grpc.authzed.com:443 tc_zed_my_laptop_deadbeefdeadbeefdeadbeefdeadbeef
zed context set dev localhost:80 testpresharedkey
zed context list

Headless usage

If you provide all context values (e.g. ZED_ENDPOINT, ZED_TOKEN) as environment variables or flags (e.g. --endpoint, --token), you do not need to set a context. You can also provide the ZED_KEYRING_PASSWORD environment variable to access an existing context in a non-interactive way.

zed schema read --endpoint grpc.authzed.com:443 --token tc_zed_my_laptop_deadbeefdeadbeef
ZED_ENDPOINT=grpc.authzed.com:443 ZED_TOKEN=tc_zed_my_laptop_deadbeefdeadbeef zed schema read
ZED_KEYRING_PASSWORD=redacted zed schema read

Debugging

The --explain flag can be used on permission check to see a trace:

zed permission check document:firstdoc writer user:emilia --explain

Acknowledgements

zed is a community project fueled by contributions from both organizations and individuals. We appreciate all contributions, large and small, and would like to thank all those involved.

In addition, we'd like to highlight a few notable contributions:

• The GitHub Authorization Team for implementing the bulk-delete command

zed's Issues

'zed context' appears to deadlock when run over a remote terminal if `DISPLAY=` is set (e.g. a remote workstation), due to keyring integration

First off, SpiceDB is very cool and seemingly the best Zanzibar implementation there is. Thanks for that! It's a fun product that I'm still wrapping my head around. Now, a quick story.

---

Last night while trying to debug a kubernetes deployment, I realized zed was hanging on any usage of the context command to manage credentials while trying to interface with the service. It was completely bizarre, and looked like this (after a kubectl proxy):

$ zed --no-verify-ca --insecure --log-level trace context set local grpc://127.0.0.1:50051 <xyz>
9:03AM DBG set log level new level=trace

In fact it was so bizarre because I had used zed previously, on another machine, to test a docker container. And I did that again to be sure I wasn't losing it, and it was just fine. It prompted me for a password for the JWT keys; I remembered that. So what could be the problem? I tried strace and nothing immediately popped out; it was waiting on a futex, which almost always means waiting on some IPC or lock mechanism; unfortunately a futex is too low level to work off of. I read the manual and saw that it integrates with the system keyring, but just writes JWT files according to the go keyring package. I confirmed it wrote those JWT files on my working machine. The source code (when I read it) seemed innocuous enough. But I couldn't figure it out.

So I went to sleep, and this morning while getting coffee it dawned on me: I thought of the words "GNOME Keyring", and realized the system where the hang occurs has a full GUI (desktop environment) active. More precisely, it is an Ubuntu Virtual Machine running a GNOME desktop (I need GNOME for some proprietary software to run its user interface on this machine). But I develop on this machine by using vscode with its powerful SSH integration to help desktop GUI latency/my Mac has better font rendering. On the other hand, the system where zed worked was completely headless and had no UI active at all. GNOME Keyring will prompt you for encryption passwords via the UX if, and only if, the GUI is active.

Sure enough, this morning I sat down, sat at VSCode on my Mac, typed in the words zed context set local ... and the hang started. I moved over and opened my Ubuntu Virtual Machine, and sure enough, the culprit causing the hang reveals itself:

---

So I honestly don't know what to do here because the actual thing is, everything is "Working as expected." So the problem is:

1. If you have a desktop active, BUT
2. You are using a remote terminal without the UI available,
3. zed context, or more precisely any usage of keyring, appears to hang

But this is all by design. It's kind of expected that if the desktop was open, you'd be using it. However it's extremely non-intuitive is this happens when you aren't using the desktop, because there is literally no possible way to tell if anything is happening.

Maybe it would be possible to just add more tracing messages, honestly? The fact I couldn't even tell what zed context was trying to do until I refreshed my memory (by using zed context successfully on the other machine) made it hard to figure out what might be happening.

There is also the more broad question of authenticating with SpiceDB in the long run. While I understand SpiceDB occupies a special infrastructural role — it being used to build your auth infrastructure means "self bootstrapping" user authorization is tricky — I suspect a simple pre-shared bearer token won't work for everyone, forever; but it is simple. So in the future assuming basic authentication came from some other mechanism the keyring might instead be avoided entirely, making this moot. I don't know (e.g. the simplest case would be to configure a CA and only allow clients with a signed proper TLS cert to connect; or ed25519, etc...)

One case I haven't checked is that my Desktop UI was actually logged into GNOME; it might be the case that if your user doesn't have a desktop login session available, then the keyring will be prompted remotely over the terminal instead (because there is no working display server for the user.) I'll test this just to be sure...

`zed` and file descriptors lead to incosistent behaviour

Expected behaviour

zed schema read > my_schema.txt
# edit the schema ...
zed schema write my_schema.txt

Actual behaviour

zed schema write my_schema.txt
{"level":"fatal","error":"rpc error: code = InvalidArgument desc = error parsing schema: parse error in `schema`, line 1, column 1: Unexpected token at root level: TokenTypeLeftBrace","time":"2021-10-28T10:36:37+02:00","message":"failed to write schema"}

This is because whenever zed detects a fd it will switch to JSON/pretty mode. This makes scripting things hard.

Possible solution

Either make formats explicit and don't do autodetection or be compatible when piping/reading into zed.

Add --no-verify-ca flag to context

Would be nice to have an option to tell a context in general to not verify CA.

Add debug support for caveats

[DUPLICATE OF 205 PLEASE IGNORE]`zed validate` Highlights wrong line on schema errors.

Add flag for check to exit(1) on false permissionship

zed permission lookup-subjects is causing a segfault

Description

➜  project git:(branch) ✗ zed version    
client: zed v0.9.1
1:26PM WRN the version of SpiceDB being called is out of date. See: https://github.com/authzed/spicedb/releases/tag/v1.17.0 latest-released-version=v1.17.0 this-version=v1.14.0
service: v1.14.0

➜  project git:(branch) ✗ zed permission lookup-subjects site:my_site granted role_binding
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x30 pc=0x100f90e30]

goroutine 1 [running]:
github.com/authzed/zed/internal/commands.lookupSubjectsCmdFunc(0x101e22700?, {0x1400056c1e0, 0x3, 0x3?})
	internal/commands/permission.go:416 +0x470
github.com/spf13/cobra.(*Command).execute(0x101e22700, {0x1400056c150, 0x3, 0x3})
	/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:916 +0x5c8
github.com/spf13/cobra.(*Command).ExecuteC(0x1400028e000)
	/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1044 +0x35c
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:968
main.main()
	cmd/zed/main.go:70 +0x510

I have a site with a relation to a role_binding and not a whole lot else in my system. I'll try upgrading the CLI, and if that doesn't work, I'll try upgrading SpiceDB.

--caveat not working in zed

relationship.go has a bug where it's not able to parse the --caveat caveatname:json value properly.
the fix should be
replace line no-267
parts := strings.Split(caveatString, ":")
with
parts := strings.SplitN(caveatString, ":",2)

error when --explain (stream terminated by RST_STREAM with error code NO_ERROR)

If we are using zed against authzed.com we can not use the "--explain" flag in a permission check.
There is always this error:

INF debugging requested on check
WRN No debuging information returned for the check
Error: rpc error: code = Internal desc = stream terminated by RST_STREAM with error code: NO_ERROR

We are using zed via brew on an apple m1.

Shell complete available contexts

Pressing tab after zed use or zed context use should shell complete to the available contexts.

Support prefix rewrites for zed import just like the playground does

When one edits a schema in the playground then imports it back into a permissions system via the "import" button, the playground automatically prepends the permission system's prefix to each reference in the schema.

However, that rewrite doesn't happen on zed import operations, making it difficult to share a common schema file with multiple permission systems; each reference in the schema has to be manually modified to include the prefix for the destination permission system.

This is a request to either:

• fetch the prefix from the destination permissions system and then automatically prepend the prefix to each reference, just like the playground (ideal)
• pass in the prefix via a command line option (not as ideal)

Zed context should store whether the context is insecure

Right now the context stores everything I need to talk to Authzed.com or a local SpiceDB except whether that connection should use TLS or not. This means that every zed request to SpiceDB needs the --insecure flag. This flag should be stored along with the rest of the context because it doesn't regularly change for a context.

Support large, batch importing of relationships

zed import currently constructs a single WriteRelationships call, which will be exceeded after ~5000 relationships. We should add support for batching the relationships to be imported into chunks, and executing those chunks in parallel.

As mentioned in Discord (https://discord.com/channels/844600078504951838/844600078948630559/949071336574181457), there are a number of issues to address:

1. The gRPC server has a limit on message sizes. This can easily be solved by batching the requests
2. Batching is tricky, serially executing each batch works to an extent, but it's not very scalable. This could be improved by executing each batch in a goroutine. Of course, this comes with some risk, as there's roughly a 9k batch size limit (see 3). If a zed import is trying to import 6 million+ rows, that's about 650 connections each trying to shove through 9k tuples.
3. Postgres and MySQL both have a limit on how many placeholders you can have in a single query. This appears to be 65535 for Postgres and MySQL (https://stackoverflow.com/a/49379324, https://stackoverflow.com/a/24447922). This roughly translating to a maximum of 9362 relationship tuple writes (assuming each is going to require 7 placeholders). I didn't initially hit this limitation because I was testing with an in memory database.

We'll need to see a reasonable limit on the number of parallelized write requests, have a progress bar for display, etc

Add explain output to failed assertFalse validations

This would be a relatively minor QOL thing from an end-user perspective, but given that zed permission check --explain can tell me all of the relations that led to a positive check, it'd be cool to have that output on failed assertFalse assertions, where the permission check was true.

Building on macOS emits a deprecation warning

mac OS version: 11.6.2

on build of cmd i get:

# github.com/keybase/go-keychain
cgo-gcc-prolog:203:11: warning: 'SecTrustedApplicationCreateFromPath' is deprecated: first deprecated in macOS 10.15 - No longer supported [-Wdeprecated-declarations]
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/SecTrustedApplication.h:59:10: note: 'SecTrustedApplicationCreateFromPath' has been explicitly marked deprecated here

Maybe we still need to have this to support old versions of Mac OS ?

Add `copy` command to relationships

Should mirror the copy command under schema

Create `login` command easily creating Authzed contexts

This requires some backend changes to the Authzed dashboard, but the end UX can be discussed here.

zed relationship read does not show caveat name and context

Implement a command for authzed.api.v0.ACLService.Lookup

A command is missing to expose the functionality from the Lookup API.

This API call lists the objects of a given type that a user has access to in a Permissions System.

A strawman for how it could be exposed it via the CLI:

zed relationship lookup user:emilia posts:read

Fix error message around missing context

See:

zed/internal/storage/config.go

Line 46 in f0f9fbc

return Token{}, errors.New("must first save a token: see `zed token save --help`")

Prevent empty passwords

For users without a keychain, zed encrypts a file in ~/.zed. I think right now it's possible to accidentally enter your initial password as empty string, which breaks future attempts to decrypt.

This bug needs to be reproduced first and then addressed. We can probably just retry the password prompt if we get an empty password.

Add command for dumping/sanitizing data for support

In order to help debug clusters without access, there could be a command that collects up as much debug information as possible and sanitizes it.

This idea was inspired by https://github.com/coreos/mayday

Docker containers using tag v0.6.0 and v0.7.0 can not find the CLI executable

I receive the following message when trying to run either of them without any arguments:

$ docker run --rm -t -i quay.io/authzed/zed # :latest, :v0.7.0 and :v0.6.0 all return the same result
exec /usr/local/bin/zed: no such file or directory

$ docker run --rm -t -i quay.io/authzed/zed:0.5.0
A client for managing Authzed from your command line.

Usage:
  zed [command]

Available Commands:
[...]

Implement flag for consistency options

We're forcing "AtLeastAsFresh" when a Zed Token is provided, but rather, there should be a flag to specify the other consistency options.

first app shell tutorial fails in "zed permission check" step

The last part in https://docs.authzed.com/guides/first-app suggests to run 4 command like

zed permission check blog/post:1 read  blog/user:emilia --revision "${ZEDTOKEN}" # true

I take that I am suppose to use the taken here as revision (which I did). I am running a local SpiceDB instance (in minikube).

For the above command I get this error:

Error: rpc error: code = Unavailable desc = last connection error: connection error: desc = "transport: Error while dialing dial tcp 192.168.9.1:50053: connect: connection refused"
Usage:
  zed permission check <resource:id> <permission> <subject:id> [flags]
...

The other terminal running the kubectl port-forward shows that it handled a connection attempt.

Versions:

zed --skip-version-check version
client: zed 0.7.5
service: v1.11.0

Also other commands do work:

zed relationship read 'blog/post'
blog/post:1 reader blog/user:beatrice
blog/post:1 writer blog/user:emilia

schema prefix check fails for multiple prefix schemas

The determinePrefixForSchema check in schema.go will fail on write and/or copy commands for schemas that have multiple prefixes within.

For example, in a schema that utilizes spicedb if there are definitions such as :

company/user company/ldap_group serviceA/items serviceB/accounts

where in serviceB/accounts there is a relation owner : company/user | company/ldap_group#member

a zed schema write ${file} fails in the determinePrefixForSchema due to the multiple prefixes in the schema.

I understand from a discord discussion that this is a protective/sanity check for Authzed schema requests. Maybe a --skip-prefix-check flag for local spicedb schema manipulation?

Add support for writing caveats and checking with caveats via zed

Support namespace when referencing subject/object in CLI args

Trying to delete a relationship, with the following command:

zed relationship delete btwb_development/document:firstdoc reader btwb_development/user:fred

returns the error

Error: rpc error: code = InvalidArgument desc = invalid WriteRequest.Updates[0]: embedded message failed validation | caused by: invalid RelationTupleUpdate.Tuple: embedded message failed validation | caused by: invalid RelationTuple.ObjectAndRelation: embedded message failed validation | caused by: invalid ObjectAndRelation.Namespace: value does not match regex pattern "^([a-z][a-z0-9_]{2,62}[a-z0-9]/)?[a-z][a-z0-9_]{2,62}[a-z0-9]$"

The following cli command:

zed relationship delete document:firstdoc reader user:fred

Works

Add a command for sanity checking clusters

Many tools (e.g. homebrew) have a doctor command that evaluates the state of the world and prints useful warnings.

Add support for lookupsubjects to zed

The LookupSubjects API is now available, so we should add the command to zed

Implement `zed relationship read`

A command to list all (or a portion of) the relationships in a Permissions System needs to be added.

There are a variety of ways it could be exposed it via the CLI:

• zed permission read <expr>
• zed relationship read <expr>
• zed relationship list <expr>

Add golanglint-ci to Build Workflow

We're using revive right now for linting in the build workflow, but it's also not configured to fail if anything is wrong.

Here's the config we use in SpiceDB:

      - uses: "golangci/golangci-lint-action@v2"
        with:
          version: "v1.42"
          skip-go-installation: true
          skip-pkg-cache: true
          skip-build-cache: false

Default Endpoint Fails due to Missing Port

The default Authzed endpoint should include the port, otherwise it fails:

$ ./zed describe skynet_dev
Error: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp: lookup grpc.authzed.com: no such host"

It should be configured to use grpc.authzed.com:443 by default.

Add command or flag to see the SpiceDB server version

Implement a command for traffic generation

In order to more effectively benchmark or assert the liveliness of a deployment, zed should have a command that generates traffic.

Running multiple zed commands using the Dockerfile

Hey,

I'm trying to run a couple zed commands in a Kubernetes job using the zed Docker image.

The recommended way to do this seems to be

command: ["/bin/sh","-c"]
args: ["zed command_1; zed command_2"]

However, I noticed the base image for the container doesn't have a shell available (or im unable to find it?)

What's the recommended way of running multiple commands on the container?

Using quay.io/authzed/zed:0.5.0 since im still running into this issue with other versions

Support writing schemas with a playground URL

Strawman design:

zed schema write https://play.authzed.com/s/deadbeefdad

Windows builds panic due to a lack of support for system-level CA pool

zed version: zed 0.1.2
system: window 10 64
use command "zed schema read", there is error info :

panic: crypto/x509: system root pool is not available on Windows
goroutine 1 [running]:
github.com/authzed/grpcutil.WithSystemCerts(0x40)
        /Users/runner/go/pkg/mod/github.com/authzed/[email protected]/dial_opts.go:28 +0x49
main.dialOptsFromFlags(0xacba20, {0xc00048e000, 0x10})
        cmd/zed/main.go:37 +0x40a
main.schemaReadCmdFunc(0x134a6a0, {0x13bb5f8, 0x0, 0x0})
        cmd/zed/schema.go:69 +0x245
github.com/spf13/cobra.(*Command).execute(0x134a6a0, {0x13bb5f8, 0x0, 0x0})
        /Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:856 +0x60e
github.com/spf13/cobra.(*Command).ExecuteC(0xc0003ecf00)
        /Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
        /Users/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:902
main.main()
        cmd/zed/main.go:93 +0x459

PrintTable ignores io.Writer argument

The printers.PrintTable function ignores its io.Writer argument, always writing to os.Stdout instead.

It doesn't seem to be causing any issues at the moment -- all call sites pass os.Stdout anyway -- but it didn't look like it was intentional either.

`zed validate` failing line indication not visible when there is no color in the terminal

I was trying to use zed validate in a pipeline that didn't support color output, but when displaying schema syntax errors, there is no way to tell which line is causing issues.

error:  could not lookup definition `undefined` for relation `writer`: unknown          
definition undefined                                
 11 |       /**
 12 |        * writer indicates that the user is a writer on the document.
 13 |        */
 14 |       relation writer: undefined
 15 | 
 16 |       /**

Suggested fix:

Either by default or with a CLI flag, use a > to indicate the failing line:

error:  could not lookup definition `undefined` for relation `writer`: unknown          
definition undefined                                
 11 |       /**
 12 |        * writer indicates that the user is a writer on the document.
 13 |        */
 14 >       relation writer: undefined
 15 | 
 16 |       /**

Run on Headless Ubuntu / Debian

I just tried to install zed on Ubuntu / Debian headless via homebrew and the .deb package.
Unfortunately upon running zed context set local localhost:50051 "somerandomkeyhere" --insecure I get a promt to set a keyring password. Well, I have never set a password and am not using Keyring.

The output I get is:

Entering your password a lot? Try setting the environment variable `ZED_KEYRING_PASSWORD`
Enter passphrase to unlock "/home/XYZ/.zed/keyring.jwt":

I don't now the password though as I have never set it and entering nothing or a random string all leads to an error.

I would expect the documentation to work which just states for macOS and Linux:

brew install zed
zed context set local localhost:50051 "somerandomkeyhere" --insecure
zed schema read --insecure

https://authzed.com/docs/spicedb/installing#running-via-brew

This might be related to #140.

If keyring is required, this would basically make zed useless in any headless setup I believe.

`zed validate` Highlights wrong line on schema errors.

I took the example RBAC schema and intentionally made an error by changing relation writer: user to relation writer: undefined . https://play.authzed.com/s/x1jQ10YQkoHl/schema

The authzed playground correctly underlined the "undefined" on line 13 as the error.

If you download the file and then run zed validate on the downloaded file, the line that gets highlighted is actually the line above the error, which is line 13 of the yaml file, rather than of the schema.

If you rearrange the keys of the yaml file, you will see that it will always mark the Nth life of the yaml file where N is the line of the schema where there is an error, rather than the line that actually contains the error.

`brew install --head` fails with ENOENT

$ brew install --HEAD zed
==> Cloning https://github.com/authzed/zed.git
Updating /Users/jzelinskie/Library/Caches/Homebrew/zed--git
From ssh://github.com/authzed/zed
   838b4a2..c3f2000  main       -> origin/main
==> Checking out branch main
Already on 'main'
Your branch is behind 'origin/main' by 51 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
HEAD is now at c3f2000 Merge pull request #41 from ecordell/release
==> Installing zed from authzed/tap
Error: An exception occurred within a child process:
  Errno::ENOENT: No such file or directory - zed

Implement end-to-end tests

There needs to be a GitHub action on this repository that uses action-spicedb for end-to-end testing of the CLI commands and flags.

Zed Command should allow the use of custom CA Certificates

The zed command currently only uses the system certificate store; However, it's easy enough under the authzed operator to use an internal CA to sign serving certificates. It would be helpful to be able to debug those with the standard zed command.

Object IDs with pipe characters not supported

Object IDs with pipe characters fail to validate and import.

For example: organization:org_f00bar#member@user:auth0|f1zzbuzz fails validation, but organization:org_f00bar#member@user:auth0_f1zzbuzz passes.

It looks like this has already been fixed in this fix in SpiceDB.

I think the only thing needed here is to update the package dependency on github.com/authzed/spicedb from 1.4.1 to 1.5.0.

Relationship read not filtering optional subject_subject_type and optional_subject_id

Relationship read with optional_relation, optional_subject_type and optional_subject_id is not return correct result.

e.g following query will return all virtue cards with parent relation. Not all virtual cards with parent relation under creditcard:cc_9MSTeIVLW0C6aHtiQSolob

zed relationship read virtualcard parent creditcard:cc_9MSTeIVLW0C6aHtiQSolob --insecure

def user{}
def account {
    relation owner: user
    permission read = owner
}
definition creditcard {
   relation parent: account
   relation owner: user
   relation viewer: user

   permission read = owner + viewer + parent->read
   permission destroy = owner
}

definition virtualcard {
   relation parent: creditcard
   relation recipient: user
   relation viewer: user

   permission read = recipient + viewer + approver + parent->read
   permission spend = recipient
   permission requestupdate = recipient
}

Linux release binaries should be statically compiled

Build distroless debug image variants

The currently build zed container images based on distroless which ships an extremely minimal environment (it doesn't even include a shell).

Would be really if you could offer variants of your images using the distroless debug base so that debugging is as simple as changing their image name to authzed/spicedb:$VERSION-debug.

analog to this topic:
authzed/spicedb#749

`zed expand <...> --json` does not match the expected schema

The JSON output of zed expand returns something like:

{
  "expandedAt": {
    "token": "GgMKATY="
  },
  "treeRoot": {
    "expandedObject": {
      "objectId": "aae48b55-ad96-11eb-a562-06368a59bfb7",
      "objectType": "care_recipient"
    },
    "expandedRelation": "agency",
    "leaf": {}
  }
}

Whereas the API returns, for the same request:

{
  "expandedAt": {
    "token": "GgMKATY="
  },
  "treeRoot": {
    "treeType": {
      "oneofKind": "leaf",
      "leaf": {
        "subjects": []
      }
    },
    "expandedRelation": "agency",
    "expandedObject": {
      "objectType": "care_recipient",
      "objectId": "aae48b55-ad96-11eb-a562-06368a59bfb7"
    }
  }
}

In the zed response, we do not have the treeType attribute