Integrations

Everything connectable lives under Integrations. Each one is connected and configured on its own page, and disconnecting is always available as a clean off-switch.

Which one do you want

GitHub

Connect a GitHub organization and pick which repositories to share. Krrim then links the work to the code.

Put the task key in a branch name, a commit message or a pull request title — KRR-142, in any case — and that task grows a Development panel showing the branches, commits and pull requests against it, with the review state of each.

Three things to know before you set it up:

• A repository does nothing until you map it to a project. That is not a formality. Task keys are unique across your workspace, so a key found in an unmapped repository would attach somebody else's pull request to a real task. The mapping is how you say the two belong together.
• Everyone links their own GitHub account, once. Without it, a task that moves itself is attributed to nobody — with it, the activity feed names the person who opened the pull request.
• Nothing writes to your repositories unless you ask. Krrim reads pull request and branch metadata. The one exception is the per-project switch that posts a comment listing the linked tasks, and it is off until you turn it on.

Working from the commit message

Once you have linked your GitHub account, a commit message can do the work:

git commit -m "KRR-142 #time 2h 30m #comment fixed the rounding #done"

• #comment <text> posts the rest of the line as a comment
• #time 2h 30m logs time against the task
• #<status> moves it — matched against your project's own statuses, so #in-review, #in_review and #In Review all find the same one

Commands run as the person who pushed, and only if they have linked their account. Anyone can write anything in a commit message, and a commit's stated author is not checked by GitHub at all — so an unlinked pusher gets their commit linked and their commands ignored. A word that names no status in your project does nothing.

Moving a task when its pull request moves

Optional, per project, and off until you choose a status:

• When a pull request opens — move the task to, say, In Review
• When it merges — move it to Done

Krrim uses your own workflow. A move your workflow does not allow is refused and recorded, not forced — and a task is never walked backwards by a webhook GitHub delivered twice.

Microsoft Teams

Connect Krrim to a Teams workspace and you get:

• Notifications in a channel for the projects you choose
• Link unfurling — a Krrim link pasted into Teams expands into the task's title, status and assignee, for people who can see it
• A Krrim tab inside Teams
• Actions from the message — assign, comment, change status without leaving

Webhooks

An HTTPS endpoint of yours that Krrim POSTs events to. Use it when another system needs to know that something happened here — a status changed, a task was created, work was escalated.

Configure in Settings → Webhooks: the URL, which events, and optionally a single project.

Practical points:

• Deliveries are signed, so you can verify they came from Krrim
• Failures retry on a fixed curve — 1m, 5m, 30m, 2h, 6h, six attempts
• Delivery history is browsable, and any delivery can be replayed
• An endpoint failing consistently is disabled automatically, and you are told

Full detail in the webhooks documentation.

Email-to-task

Give a project an intake address and mail sent to it becomes a task — subject as the title, body as the description.

Useful for support queues and for stakeholders who will never open Krrim but will always send an email.

Requires DNS setup — an admin does it once per workspace.

Public API

Scoped tokens for your own code. A token authenticates a service account with a role you choose, carries only the scopes you grant it, and can be restricted to specific projects and source IPs.

Start with the developer quickstart.

Webhooks or the API?

Push versus pull:

• A webhook tells you the moment something happens, and costs you no rate limit.
• The API answers questions on your schedule, including ones no event covers.

Most solid integrations use both — webhooks for latency, and a periodic pass over the changes feed as the backstop for anything a delivery outage outlived.