anytype
An ergonomic Anytype API client in Rust.
Home | Documentation | Examples
Overview
anytype provides an ergonomic rust client for Anytype. It supports listing, searches, and CRUD operations on Objects, Properties, Spaces, Tags, Types, Members, and Views, with optional key storage and caching. gRPC extensions (enabled by default) add file operations and chat streaming.
Applications authenticate with Anytype servers using access tokens. One token is required for http apis, and if gRPC apis are used (for files or chats), an additional gRPC token is required. The anytype library helps generate tokens and store them in a KeyStore.
Features
- 100% coverage of Anytype API 2025-11-08
- Optional gRPC back-end provides API extensions for features not available in the REST api (Files and Chats)
- Paginated responses and async Streams
- Integrates with OS Keyring for secure storage of credentials (HTTP + gRPC)
- Http middleware with debug logging, retries, and rate limit handling
- Client-side caching (spaces, properties, types)
- Nested filter expression builder
- Parameter validation
- Metrics
- used in:
Quick start
use *;
const PROJECT_SPACE: &str = "Projects";
const CHAT_SPACE: &str = "Chat";
//! Agenda automation:
//! - list top 10 tasks sorted by priority
//! - list 10 most recent documents containing the text "meeting notes"
//! - send the lists in a rich-text chat message with colors and hyperlinks
async
See the Examples folder for more code samples.
Files (gRPC)
File operations require the grpc feature (enabled by default).
let file_id = "file_object_id";
let path = client
.files
.download
.to_dir
.download
.await?;
println!;
Chat Streaming (gRPC)
Streaming chat updates requires the grpc feature (enabled by default).
use *;
use StreamExt;
// print chat messages as they arrive
async
Status and Compatibility
The crate has 100% coverage of the Anytype REST api 2025-11-08.
Plus:
-
View Layouts (grid, kanban, calendar, gallery, graph) implemented in the desktop app but not in the api spec 2025-11-08.
-
gRPC back-end provides API extensions for features not available in the REST api:
- Files api for listings, search, upload, and download.
- Chat message operations and streaming subscriptions.
Apis not covered
The current Anytype http backend api does not provide access to some data in Anytype vaults.
FilesUpdate (as of v0.3.0): Files support now available with the gRPC back-endChats and MessagesUpdate (as of v0.3.0): Chat operations and streaming now available with the gRPC back-end- Blocks. Pages and other document-like objects can be exported as markdown, but markdown export is somewhat lossy, for example, in tables, markdown export preserves table layout, with bold and italic styling, but foreground and background colors are lost.
- Relationships - only a subset of relation types are available in the REST api.
Keystore
A Keystore stores authentication tokens for http and grpc endpoints. Various implementations store keys in memory, on disk, or in the OS Keyring
More info about using and configuring keystores is in Keystores
Known issues & Troubleshooting
See Troubleshooting
For keystore-related issues, see Keystores
Eventual Consistency
Anytype servers have "eventual consistency" (This is a feature of practical distributed systems, not a bug!). How you might encounter this in your programs:
- Create a new property and then immediately create a type with the property, and get an error that the property does not exist.
- Create a new type and then create an object with the type, and get an error that the type does not exist.
- Delete an object, then immediately search for it, and find it.
The amount of time needed for "settling" seems to be 1 second or less.
anytype can perform validation checks after creating objects (objects, types, properties, and spaces) to ensure they are present before create() returns. Since this verification can cause delays, it's opt-in. While there are some knobs you can tune to adjust backoff time and number of retries, the easiest way to add verification is to call ensure_available() before create for critical calls:
let obj = client.new_object.name.ensure_available.create.await?;
To enable verification for all new objects, types, and properties, add .ensure_available(VerifyConfig::default()) to the config when creating the client. Setting this in the client configuration is not recommended except for an environment like unit tests where you're hammering the server and need to get results immediately. If verification is enabled in the client config, it will be applied to all create calls, unless disabled on a per-call basis by using .no_verify():
let obj = client.new_object.name.no_verify.create.await?;
Building
Requirements:
- protoc (from the protobuf package) in your PATH. On macos,
brew install protobuf - libgit2 in your library path.
Testing
Set environment flags for unit and integration tests. You'll also need a running anytype server (cli or desktop).
# HTTP endpoint. Default: http://127.0.0.1:31012
# Headless cli default port is 31012. Desktop app uses port 31009
# Set the same for ANYTYPE_TEST_URL
# optional: set keystore to custom path
# optional: set space id for testing. If not set, uses first space with "test" in the name
# optional: enable debug logging. Default "info"
# optional: disable rate limits. If not disabled, tests will take longer to run
Run smoke test
Run all tests
cargo test -- --nocapture
Integration tests require a running Anytype server and environment variables. See src/client.rs for details.
License
Apache License, Version 2.0
Contributing
Feedback, Issues and Pull Requests are welcome.