canonical: https://jentic.com/apis/lgtm.com/lgtm-main

# LGTM API specification

Jentic publishes the only available OpenAPI specification for LGTM API specification, keeping it validated and agent-ready. LGTM is the code-analysis platform from Semmle that runs CodeQL queries to find security vulnerabilities and code-quality issues across open-source and enterprise projects. The 29-endpoint REST API lets developers add and configure projects, trigger and inspect analyses, run code reviews on patches, submit CodeQL query jobs, manage CodeQL database snapshots, and check long-running operation status. It is the programmatic surface for integrating LGTM analysis into custom CI flows and enterprise governance.

## For AI agents

Run CodeQL analyses, trigger code reviews on patches, submit query jobs, and manage projects and snapshots on the LGTM code-analysis platform.

## Scope

Does not handle dependency scanning, container scanning, or runtime application security - use for CodeQL static analysis, code review, and query jobs only.

## Capabilities

- Add and remove analysed projects via POST /projects and DELETE `/projects/{project-id}`
- Trigger analysis of a specific commit through POST `/analyses/{project-id}` and inspect alerts via GET `/analyses/{analysis-id}/alerts`
- Run code review on a patch with POST `/codereviews/{project-id}` and retrieve results from GET `/codereviews/{review-id}`
- Submit and monitor CodeQL query jobs across multiple projects using /queryjobs and `/queryjobs/{queryjob-id}/results`
- Configure project-level analysis settings through GET and PUT `/projects/{project-id}/settings/analysis-configuration`
- Upload and download CodeQL database snapshots using `/snapshots/uploads` and `/snapshots/{project-id}/{language}`
- Track long-running tasks and platform health with `/operations/{operation-id}` and `/system/health`

## Use cases

### CI-gated security analysis on commits

Engineering teams plug LGTM into their CI pipeline to run CodeQL on every meaningful commit. The CI step calls POST `/analyses/{project-id}` with the commit id, polls GET `/analyses/{analysis-id}`, then pulls `/analyses/{analysis-id}/alerts` to surface new vulnerabilities directly in the PR. This catches taint-flow and injection bugs before merge rather than at quarterly review.

Example prompt: Trigger POST `/analyses/{project-id}` with commit_id 'a1b2c3d', poll GET `/analyses/{analysis-id}` until complete, and post any alerts as PR comments.

### Pre-merge code review on patches

Reviewers want a second machine opinion before approving a patch. POST `/codereviews/{project-id}` runs CodeQL against the patch and GET `/codereviews/{review-id}` returns the diff-scoped alerts. Reviewers see only issues introduced or affected by this change, focusing the conversation on what the patch actually does.

Example prompt: Submit a patch via POST `/codereviews/{project-id}`, then GET `/codereviews/{review-id}` once complete and return only the alerts introduced by the patch.

### Cross-project CodeQL queries for security research

Security researchers run a single CodeQL query across many projects to study the prevalence of a vulnerability pattern. POST /queryjobs submits the query, GET `/queryjobs/{queryjob-id}/results` returns a summary, and per-project results come from GET `/queryjobs/{queryjob-id}/results/{project-id}.` This is the programmatic equivalent of variant analysis at scale.

Example prompt: POST /queryjobs with a CodeQL query and a list of project-ids, then walk GET `/queryjobs/{queryjob-id}/results` to enumerate findings per project.

### AI agent vulnerability triage via Jentic

An AI security agent triages new alerts every morning. Through Jentic the agent searches for 'list new code analysis alerts' or 'trigger an analysis', loads the matching LGTM operation, and executes with the access token held in your Jentic One instance. Findings are summarised and routed to the owning team without raw bearer tokens ever entering agent context.

Example prompt: Use Jentic to search 'get analysis alerts for a project', load GET `/analyses/{analysis-id}/alerts`, and summarise the new high-severity alerts since yesterday.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/analyses/{project-id}` | Run analysis of a specific commit. |
| GET | `/analyses/{analysis-id}/alerts` | Get detailed alerts for an analysis. |
| POST | `/codereviews/{project-id}` | Run code review for a patch. |
| POST | `/queryjobs` | Submit a CodeQL query job. |
| GET | `/queryjobs/{queryjob-id}/results` | Get summary of query job results. |
| POST | `/projects` | Add a project to LGTM. |
| GET | `/projects` | List projects. |
| GET | `/operations/{operation-id}` | Get operation status. |

## Key resources

- **Projects** — Add, remove, and configure projects analysed by LGTM.
- **Analyses** — Trigger and inspect CodeQL analyses on specific commits.
- **Code reviews** — Run CodeQL against a patch and retrieve diff-scoped alerts.
- **Query jobs** — Submit and monitor cross-project CodeQL query runs.
- **Snapshots** — Upload and download CodeQL database snapshots.
- **Operations** — Check the status of long-running analysis or query tasks.
- **System** — Read system health and usage metrics.

## Why Jentic

- **Setup:** Wiring the LGTM API by hand means creating and sending a bearer access token, tracking asynchronous operation ids across analyses and query jobs, and calling lgtm.com/api/v1.0 yourself. Through Jentic you install once, import the LGTM API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** LGTM puts the project id in the URL path (`/analyses/{project-id}`, `/codereviews/{project-id}`), so a rule can pin your agent to one project: it can request analyses and read alerts there. You choose the operations it may call, so submitting query jobs or creating projects is not included unless you add them.
- **Credential handling:** Your LGTM bearer token 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 'analyse a commit for vulnerabilities' or 'run a CodeQL query across projects', and Jentic returns the matching LGTM operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Snyk API** — Developer-focused vulnerability scanner with a strong dependency-and-container story alongside SAST.
- **SonarCloud API** — Code-quality and security platform with rule-based static analysis across many languages.
- **GitHub API** — Source control and CI hub that hosts the projects LGTM analyses and where alerts are surfaced.

## FAQ

### Why is there no official OpenAPI spec for LGTM API specification?

LGTM does not currently publish a maintained OpenAPI specification on its own domain. Jentic generates and maintains this spec so that AI agents and developers can call LGTM via structured tooling. It is validated against the API surface and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the LGTM API specification use?

Calls are authenticated with an HTTP Bearer access token created in Account settings under 'Create token'. Enterprise users always need a token; LGTM.com users need one to submit CodeQL queries, request analyses, or check long-running operations. Through Jentic the access token is stored in your Jentic One instance.

### Can I trigger an analysis on a specific commit through this API?

Yes. POST `/analyses/{project-id}` accepts a commit id and queues a CodeQL analysis run. The response includes an analysis-id you can poll at GET `/analyses/{analysis-id}` and pull alerts from at GET `/analyses/{analysis-id}/alerts` when complete.

### What are the rate limits for the LGTM API?

LGTM applies token-scoped rate limits but does not publish exact figures in the OpenAPI spec. Long-running work (analyses, query jobs) returns operation ids you can poll at GET `/operations/{operation-id}` rather than blocking, which is the recommended pattern for high-volume integrations.

### How do I run a CodeQL query across multiple projects through Jentic?

Install with 'pip install jentic', search for 'run a CodeQL query against multiple projects', and Jentic returns POST /queryjobs. Load the schema, supply your CodeQL query and target project ids, and execute. Then poll GET `/queryjobs/{queryjob-id}` until results are ready.

### Can I download CodeQL database snapshots with this API?

Yes. GET `/snapshots/{project-id}/{language}` downloads a snapshot for a specific language, and the `/snapshots/uploads/{session-id}` endpoints support uploading a database back to LGTM. This is how teams move CodeQL databases between LGTM and local CodeQL CLI workflows.

### Can I limit what my agent is allowed to do with the LGTM API?

Yes. Because you run Jentic One yourself, your own rules decide which LGTM operations and credentials the agent may use. Since LGTM puts the project id in the URL path, such as POST `/analyses/{project-id}` and POST `/codereviews/{project-id}`, a rule can pin the agent to a single project so it only requests analyses and reads alerts there. You choose the operations it may call, so submitting query jobs at POST /queryjobs or creating projects at POST /projects stays off unless you add them.