API
Building Internal Tools with the Repokit API
Use the API when your integration is application-first and you want explicit control over requests, responses, and how ranked files feed into your workflow.
When the API is the right access path
- You are building a backend or internal platform feature.
- You want explicit HTTP + JSON control.
- You do not need a tool protocol wrapper because your environment already owns the request flow.
What your tool should send
At minimum, send the repository identifier, a concrete task description, and a top-k value that fits your workflow.
Add supporting context only when it genuinely sharpens the likely implementation surface.
What your tool should do with the result
- Show the ranked files in inspection order.
- Preserve the scores and explanations for operator judgment.
- Route the user into verification rather than hiding the underlying retrieval step.
What not to promise
Do not present the API as autonomous code generation. The narrow, credible claim is that it improves the starting point for repository-specific work.
Where to start
Begin with the human-facing API page and docs, then wire the raw endpoint into your own internal tool once the verification flow is clear.
Next up
Use the shortest path through submission, readiness, verification, API, and MCP.
Related reading
API vs MCP for Repository-Aware Retrieval
Choose the access path that matches your workflow: direct HTTP control or tool-based retrieval through MCP.
Read articleHow to Use MCP with a Single Repository
A narrower MCP workflow for agent builders who want repository-aware retrieval without drifting into broad multi-repo context or vague tool usage.
Read articleHow to Interpret Ranked File Results
Use the ranked shortlist as an inspection order, not as a blind answer, and learn what the scores and neighboring files are actually telling you.
Read articleFeatured paths
If the next useful move is clearer than another article, take it.
Use the main Repokit paths to move from blog reading into docs, submission, API, or MCP without leaving the same funnel.
Debugging path
Start with a regression or failing test.
Use ranked files to narrow the likely implementation surface before you spend time browsing or guessing.
Verification path
Understand ready, tokens, and the real beta flow.
Use the verification and readiness content to judge the product on your own code instead of on generic examples.
API path
Build an internal tool with direct HTTP control.
Go from human-facing API guidance into a real integration once the verification flow and repository boundary are clear.
MCP path
Connect a tool-capable client through MCP.
Keep the scope narrow to one repository and one retrieval task before you try to scale the workflow outward.