For Agents
Create and update Kitemaker work items, attach comments, capture customer feedback, and read recent activity from a Kitemaker space.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Kitemaker REST API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fkitemaker.co%2Fkitemaker" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fkitemaker.co%2Fkitemaker" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with Kitemaker REST API.
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
GET STARTED
Use for: Create a new work item in the Engineering space, Update the status of work item ENG-123 to in progress, Add a comment to work item ENG-123, Capture customer feedback against an initiative
Not supported: Does not host source code, run CI, or manage user accounts - use for Kitemaker work items, comments, initiatives, and feedback only.
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.
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
Patterns agents use Kitemaker REST API for, with concrete tasks.
★ 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.
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.
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.
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.
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.
Search Jentic for 'create a Kitemaker work item', load POST /workitem, and execute it with the supplied title, description, and spaceKey.
16 endpoints — jentic publishes the only available openapi specification for kitemaker rest api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/workitem
Create a work item
/workitem
Update a work item
/workitem
Read a work item by space key and number
/comment
Comment on a work item
/feedback
Create a feedback entry
/initiative
Create an initiative
/recent/workitems
List recently updated work items
/metadata/statuses
List statuses for a space
/workitem
Create a work item
/workitem
Update a work item
/workitem
Read a work item by space key and number
/comment
Comment on a work item
/feedback
Create a feedback entry
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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.
Alternatives and complements available in the Jentic catalogue.
GitHub API
GitHub holds the code that the work items in Kitemaker reference
Pair with GitHub when a Kitemaker work item should be cross-referenced with a pull request
Specific to using Kitemaker REST API through Jentic.
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.
/initiative
Create an initiative
/recent/workitems
List recently updated work items
/metadata/statuses
List statuses for a space