Endpoint reference¶
Every endpoint the API serves, grouped by the product area that owns it. All of them live under
https://api.trilocore.ai, and all but the four public
attestation and report endpoints take an Authorization: Bearer header:
New to the API? Start with the overview and authentication — this section assumes both.
How the reference is organised¶
363 endpoints across 22 pages, grouped by the product namespace that owns them: every endpoint is documented once, under its canonical path. Large products are split into several focused pages by resource area.
Within a page, endpoints are listed alphabetically by path, each with a method badge. Every entry carries the same four-row table:
| Row | What it tells you |
|---|---|
| Authentication | which credential is accepted |
| Idempotency-Key | whether the header is required — see Idempotency |
| Success | the status code a successful call returns |
| Upstream | the service that ultimately handles the request |
Where a machine-readable schema exists, a Request body table follows, listing each field with its type, whether it is required, and any length or size constraints. Some entries do not have one yet; their request shape is not published in a machine-readable form, and the curl example shows the call without a body. That is a gap in the documentation, not a statement that the endpoint takes no body.
A few entries carry a "Not available" warning. Those belong to the AI plane, which is not currently running: the call is routed but fails at the service behind the front door. They are listed rather than hidden so that the reference matches what the API actually advertises.
Anything not listed here returns 404
The API answers only the paths in this reference. There is no undocumented surface to
discover, and paths from previous versions of these tools have been removed — a call to one
is a 404, not a redirect. If you are porting an old integration, re-derive every path from
this reference rather than adjusting the ones you have; see
Deprecations.
Remember that an unauthenticated request to a non-existent path answers 401, not 404.
Authenticate before concluding that a path is missing.
EVM auditing tools — /api/v1/bevm/¶
Fork-backed analysis of deployed contracts: sessions, targets, execution, state, findings.
| Page | Endpoints | Covers |
|---|---|---|
| Sessions and forks | 31 | Opening a fork, and every operation on it: transactions, snapshots, balances, storage, blocks, deployments, recordings, provenance seals |
| Targets and contracts | 30 | Targets, contracts, compilation, the preset library, graphs, mindmaps |
| Analysis and findings | 15 | Scans, jobs, analysis jobs, asset flow |
| Execution | 7 | Recorded executions, stateless calls and deployments |
| State and storage | 3 | MorphVM, mapping-key computation |
| Recordings, history and provenance | 2 | History entries, recipe hints |
| Service | 1 | Health |
Solana auditing tools — /api/v1/bsvm/¶
| Page | Endpoints | Covers |
|---|---|---|
| Solana sessions and programs | 18 | Opening a Solana fork, transactions, airdrops, passive scans, program CFG, heap and traces |
Shared workbench — /api/v1/workbench/¶
What the EVM and Solana auditing tools share, whichever chain a session runs on.
| Page | Endpoints | Covers |
|---|---|---|
| Workbench | 32 | Audit events, exports, retention, legal holds, destinations, residency, your audit view, long-running operations, artifacts |
Radar — /api/v1/radar/¶
| Page | Endpoints | Covers |
|---|---|---|
| Radar: contract code search | 4 | Searching and counting deployed contract code (many facet counts in one request), and reading one code family |
Workspaces and engagements — /api/v1/workspaces/¶
Organisation-level structure: teams, workspaces, projects, contract inventory, findings, notes, and the Audit Passport attestation chain.
| Page | Endpoints | Covers |
|---|---|---|
| Workspaces | 78 | Members, teams, contracts, audits, reports, attestations, access reviews |
| Projects | 18 | Projects, members, invitations, audit logs, content transfers |
| Contract index | 2 | Cross-workspace contract inventory |
| Audit index | 2 | Cross-workspace audit index and publications |
| Activity | 1 | The activity feed |
| Invitations | 1 | Accepting an invitation |
| Notes | 13 | Note spaces, notes, comments, events, images |
Contract IDE — /api/v1/ide/¶
The developer surface: git-native workspaces, compilation, review and publishing.
| Page | Endpoints | Covers |
|---|---|---|
| Workspaces and files | 39 | Workspaces, files, branches, tags, members, publishing bindings |
| Review, audits and evidence | 26 | Annotations, merge requests, audits, evidence |
| Compilation and integrations | 10 | Compilation, toolchains, templates, integrations |
Architecture — /api/v1/arch/¶
| Page | Endpoints | Covers |
|---|---|---|
| Architecture | 26 | Architecture documents, builds, analyses, snapshots, diffs, threats, traces, project transfers |
It paginates with page_size and page_token.
Public endpoints — /api/v1/public/¶
| Page | Endpoints | Covers |
|---|---|---|
| Public (unauthenticated) | 4 | Attestation verification, the signing key set, shared reports |
These four are the only endpoints that need no credential — they exist so that a third party can verify an attestation or open a shared report without a Trilocore account. They are rate limited per client IP; see Rate limits.
A note on completeness¶
This reference is generated from the API's own routing tables and the owning services'
schemas, rather than hand-maintained — so it is complete by construction rather than by anyone
remembering to add a page. It is a snapshot, though, not a live view: it is regenerated
deliberately, so a route added to the gateway since the last regeneration would not appear here.
The machine-readable specification at /api/v1/meta/openapi.json is generated from the same
tables and describes the same surface.