canonical: https://jentic.com/apis/kitemaker.co/kitemaker # Kitemaker REST API Jentic publishes the only available OpenAPI specification for Kitemaker REST API, keeping it validated and agent-ready. Kitemaker is a project-management tool for product teams, and the REST API exposes the work item, initiative, feedback, comment, and label model along with read-only metadata for spaces and statuses. Operations cover creating and updating work items, attaching comments and labels, recording customer feedback, and reading the recent activity feed needed by external dashboards. Authentication is via an X-API-Key header. ## For AI agents Create and update Kitemaker work items, attach comments, capture customer feedback, and read recent activity from a Kitemaker space. ## Scope Does not host source code, run CI, or manage user accounts - use for Kitemaker work items, comments, initiatives, and feedback only. ## Capabilities - Create and update work items inside a Kitemaker space - Attach comments to existing work items - Create and apply labels to organise work items - Capture customer feedback and link it to work items or initiatives - Create and read initiatives that group related work items - Read recently updated work items and comments for dashboards - List the spaces, statuses, and labels available on the organisation ## Use cases ### File bug reports from a support tool When a support engineer escalates a bug, an integration can call POST /workitem with the title, description, and the bug label ID. The work item enters the engineering space immediately and the support tool gets back the work item identifier so it can deep-link the customer ticket to the engineering record. Example prompt: POST a payload to /workitem with title, description, spaceKey, and labelIds, then return the work item key to the support tool. ### Customer feedback to roadmap loop Customer-facing teams can call POST /feedback to log a customer's request and link it to an existing initiative. The same record surfaces in the Kitemaker roadmap view, so the product team can weigh demand without leaving their tool. Example prompt: POST a feedback entry to /feedback with the customer quote and the initiative number it relates to. ### External activity dashboard Engineering managers can build a wallboard by calling GET `/recent/workitems` and GET `/recent/comments` on a short interval. The two endpoints return enough metadata to render a feed of recent updates without polling each individual work item. Example prompt: Poll GET `/recent/workitems` every minute and write the latest 20 entries to a status board. ### Comment automation from a code review When a code review finishes, a CI step can call POST /comment to drop a note on the relevant Kitemaker work item, capturing the merge or review outcome alongside the engineering record. Combined with PUT /workitem, the same workflow can flip the work item to a done status. Example prompt: POST a comment to /comment with the work item ID and the merge details, then PUT /workitem to flip its status to done. ### Agent integration via Jentic A product-ops agent can use Jentic to discover the Kitemaker work item operations, load their schemas, and execute them with a vaulted X-API-Key. The agent files bugs, applies labels, and reads recent activity without seeing the raw key. Example prompt: Search Jentic for 'create a Kitemaker work item', load POST /workitem, and execute it with the supplied title, description, and spaceKey. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/workitem` | Create a work item | | PUT | `/workitem` | Update a work item | | GET | `/workitem` | Read a work item by space key and number | | POST | `/comment` | Comment on a work item | | POST | `/feedback` | Create a feedback entry | | POST | `/initiative` | Create an initiative | | GET | `/recent/workitems` | List recently updated work items | | GET | `/metadata/statuses` | List statuses for a space | ## Key resources - **Work Items** — Create, update, and retrieve work items by space key and number - **Comments** — Add and list comments on work items - **Initiatives** — Create and read initiatives that group work items - **Feedback** — Capture customer feedback and link it to work items or initiatives - **Labels** — Create and list labels used on work items - **Metadata** — List spaces, statuses, work items, and labels for an organisation - **Organization** — Read organisation-level information ## Why Jentic - **Setup:** Wiring Kitemaker by hand means learning its X-API-Key header auth and handling the toil.kitemaker.co REST host and its errors yourself. Through Jentic you install once, import Kitemaker from the API Directory, store the key once, and your agent calls it. - **Permission scoping:** Kitemaker carries the work item, comment, and initiative in the request body rather than as a URL path resource, so scope by operation: limit the agent to the operations it needs, such as creating work items or reading statuses, and leave initiative or feedback writes out unless you add them. - **Credential handling:** Your Kitemaker API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'create a work item' or 'add a comment to an item', and Jentic returns the matching Kitemaker operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Linear API** — Linear is a similar issue tracker for product engineering teams - **ClickUp API** — ClickUp is a broader work management platform with task and document features - **GitHub API** — GitHub holds the code that the work items in Kitemaker reference - **Slack API** — Slack delivers Kitemaker activity-feed updates to engineering channels ## FAQ ### Why is there no official OpenAPI spec for Kitemaker REST API? Kitemaker does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Kitemaker REST API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Kitemaker REST API use? Kitemaker authenticates with an X-API-Key header. Jentic stores the key in its vault and injects it on each call, so the agent process never reads the raw value. ### Can I create a work item with the Kitemaker REST API? Yes. POST to /workitem with the title, description, spaceKey, and any labelIds you want applied. Update the work item later with PUT /workitem and add comments with POST /comment. ### What are the rate limits for the Kitemaker REST API? The OpenAPI specification does not declare explicit rate limits across the 16 endpoints. Use GET `/recent/workitems` and GET `/recent/comments` for activity feeds rather than polling individual work items, and back off if the API returns a 429. ### How do I create a Kitemaker work item through Jentic? Run pip install jentic, search Jentic for 'create a Kitemaker work item', load the POST /workitem operation, and execute it with title, description, and spaceKey. Jentic supplies the X-API-Key header from the vault. ### Can I limit what my agent is allowed to do with the Kitemaker REST API? Yes. Because you run Jentic One yourself, your own rules decide which Kitemaker operations and credentials the agent may use. Since Kitemaker carries the work item, comment, and initiative in the request body rather than as a URL path, you scope by operation: allow only what the agent needs, such as POST /workitem to create work items or GET `/metadata/statuses` to read statuses, while leaving POST /feedback and POST /initiative writes out unless you add them. The X-API-Key is held by your instance and injected at execution time, so the agent can only reach the operations you permit.