Krrim for developers
A REST API over the same endpoints the Krrim app uses, reachable with scoped tokens that authenticate a service account rather than a person.
Krrim's public API is not a parallel surface built alongside the product. It is an allowlist over the endpoints the application itself calls — the same paths, the same serializers, the same permission checks. When a board renders a task, it reads the endpoint you read.
That has one consequence worth knowing up front: what you can reach is not
"everything under /api/v1/". It is the published subset documented here, and
a path that is not on that list refuses a token no matter how many scopes it
carries. Default deny, on purpose.
The three things that shape every request
A token is a service account
Not a person. It has its own role in the workspace, so offboarding an employee never breaks a production integration.
Scopes narrow it further
Effective permission is the service account's role intersected with the token's scopes and its optional project restriction.
You call your own workspace host
Requests route by Host. A token presented to another workspace's host is
rejected with a distinct error code rather than silently misbehaving.
Base URL
Every request goes to your own workspace subdomain:
https://<your-workspace>.krrim.com/api/v1/There is no shared api.krrim.com. The host is how a request finds its
Postgres schema, which is also why a token is bound to the workspace that
issued it.
Start here
Quickstart
Mint a token and make your first authenticated request.
API reference
Every published endpoint, grouped by resource, with the scope each needs.
Webhooks
Signed events pushed to you, so you are not polling for changes.
Changes feed
Delta sync that carries deletions — which a task list, by definition, cannot.
The live schema
The OpenAPI 3 document is served from your workspace and is the machine-readable contract these pages describe in prose:
| Schema | GET /api/v1/public/schema/ |
| Reference UI | /api/v1/public/docs/ |
Both are open — no token required. A developer deciding whether to build against Krrim does not have one yet, and a schema behind a login is a schema nobody reads. Neither carries workspace data; they describe only the published surface.
The schema is generated from the code and committed to the backend repository, where a test fails if the two drift apart. If a page here disagrees with the schema, the schema is right — please tell us.