Connecting software to Asanable

Nothing here can edit a card’s content, or delete anything. The REST API has exactly three writes — post a comment, set a field on a card, and post a version of a card’s AI review — and it cannot change a title, a description, an assignee, a due date, a label or a column. The MCP connector’s writes (a comment, a card, a subtask, a move between columns — amendments 240/291/294/311) act only as the member who authorised the connection, never anonymously. Webhooks only ever report that something happened.

Field writes were added in amendment 225, and the condition on them is the same one that had ruled them out: every change names whoever made it. A card’s activity log now reads “Invoice Checker set AI Reviewed to Yes”, with the machine account’s own name and colour, exactly as its comments carry them — and setting a field needs its own scope, so no token minted for commenting gained the power.

The AI review was added in amendment 247, and it is the one write that is deliberately quiet. A reviewing agent used to post its analysis as a comment, which paged everyone following the card every time the ticket changed; it now goes into a versioned section of the card that names the machine account beside every version and notifies nobody. It has its own scope too, so the same rule holds: the credential that posts reviews is not the credential that could post comments.

The two incoming integrations do write, and they are the exception that shows the rule rather than a hole in it: each is one named service, wired up by an operator who holds its signing secret — Aikido filing into one column of one board an operator named, GitHub commenting only about pull requests inside the organisation’s own repositories, a fork’s being ignored precisely so that “anybody on the internet” is not a way to put a remark on a card. Neither is an endpoint anybody can call, and there is nothing here that would let you become one.

The rule behind all of it is worth reading once: every write in Asanable is attributable to somebody who can be asked about it. A comment satisfies that on its face — it carries its author’s name and avatar on the card. A field did not, which is why programs could not set one; now the activity log records who set it, so it does, and it is allowed. A title, a description, an assignee or a column move still have no such answer, so they are still nobody’s to change but a person’s.

Nothing is provisioned from outside. A member authorises their own Claude connection, an admin adds a webhook endpoint, an admin mints an API token for a machine account they created (or a member mints a read-only one for themselves), an operator pastes Aikido’s secret into the deployment, and an operator pastes GitHub’s. There is no endpoint that hands out any of the five, which is why this page can be public without being a way in.

A card’s name is its reference. AI-42 is the board key and the card’s number, and it is what people say out loud. Both surfaces speak it: the MCP tools take it as an argument, a webhook body carries it, and every deep link is /b/AI?card=AI-42.

A webhook never hands over prose about people. A webhook body has nowhere to put a description or a comment body — it is pushed to a URL somebody typed into a settings page, and that destination has been vetted by nobody. The two pull surfaces do return prose, because a caller has to hold a credential first: Claude reads only what the member who authorised it can read, and the REST API reads only what the token an admin minted permits. The reasoning is on each page, because it is a deliberate distinction rather than an inconsistency.