Calls without X-API-Key need no key. Calls with it need a paid plan — get a key.
Get an API key
Free tier, no form to fill in. Signing in shares your email address with us — we
store it to create your key and to recognise you if you sign in with another
provider. See our Privacy Policy and
Terms.
openapi: 3.2.0
info:
title: Craaft Comments API
version: 1.0.0
description: 'Personal-access-token API for Craaft. See `docs/api.md` for the
narrative guide, rate limits, and worked examples.'
contact:
name: Craaft
servers:
- url: https://craaft.io/api/v1
description: Production
- url: http://localhost:8080/api/v1
description: Local
security:
- bearerAuth: []
tags:
- name: Comments
paths:
/comments/{id}:
parameters:
- name: id
in: path
required: true
schema:
type: string
format: uuid
patch:
summary: Edit (author only)
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- body
properties:
body:
type: string
maxLength: 5000
description: Markdown. Capped at 5000 characters; longer bodies return 400.
responses:
'200':
description: Updated
content:
application/json:
schema:
$ref: '#/components/schemas/Comment'
tags:
- Comments
operationId: patchCommentsById
x-operation-id-source: derived
delete:
summary: Delete (author or workspace owner/admin)
responses:
'204':
description: Deleted
tags:
- Comments
operationId: deleteCommentsById
x-operation-id-source: derived
components:
schemas:
Comment:
type: object
required:
- id
- cardId
- authorId
- body
- createdAt
properties:
id:
type: string
format: uuid
cardId:
type: string
format: uuid
authorId:
type: string
format: uuid
body:
type: string
maxLength: 5000
createdAt:
type: string
format: date-time
updatedAt:
type: string
format: date-time
securitySchemes:
sessionAuth:
type: apiKey
in: cookie
name: craaft_session
description: 'Browser session cookie (`__Host-craaft_session` in production,
`craaft_session` in dev), set at sign-in. Not obtainable through
this API - it''s here only so the handful of session-only routes
below (the OAuth consent screen''s own endpoints, connected-apps
management) can be marked accurately. They reject both bearer
schemes with a 403.
'
bearerAuth:
type: http
scheme: bearer
bearerFormat: cra_<24 base64url chars>
description: 'Two token schemes, same permissions. `cra_<24 base64url chars>` is a
personal access token minted in Settings, doesn''t expire on its own,
and is revoked from the same page. `cro_<32 base64url chars>` is an
OAuth access token issued to an OAuth client (an MCP client such as
Claude) via the authorization-code-with-PKCE flow; it expires after
1 hour and the client refreshes it. Either token authenticates as
the user who authorized it, with that user''s exact permissions.
A token can be read-only: a personal access token created with
access `read`, or an OAuth grant with scope `craaft:read`. A
read-only token can send GET, HEAD and OPTIONS; any other method
gets `403` with "this token is read-only; this request needs a
token with read and write access", before the request is handled.
A token can also be limited to chosen boards. Other boards then
behave as if they don''t exist (`404`, or left out of lists), and
`POST /projects`, `/imports`, `/members` and `/invitations` answer
`403` with "this token is limited to some boards; this request
needs a token for all boards".
OAuth clients discover every endpoint they need - authorization,
token, dynamic client registration, revocation - at
`/.well-known/oauth-authorization-server` (RFC 8414); they don''t
need to be told the URLs out of band.
'