Automating Vexta with Its REST API: Jobs, Scans and Assets

Can a vulnerability scanner be driven entirely from a script instead of a browser? Yes: Vexta exposes a REST API under a single versioned path, `/api/v1/`, that covers everything from starting a scan to pulling back its findings, so scanning can be kicked off, monitored and consumed from a hunter's own tooling rather than a UI. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and because the same API backs its own dashboard, anything the UI can do is something the API can do too.

Why automate a scanner instead of clicking through it?

A hunter running the same class of scan across dozens of targets, or a team wiring vulnerability scanning into a broader internal workflow, hits the limits of a UI fast. Starting a scan by hand, waiting, then manually exporting a report does not scale past a handful of targets, and it does not fit into anything that needs to run unattended on a schedule or in response to another event.

An API that mirrors what the dashboard does closes that gap. Every core action, logging in, kicking off a scan, checking on it, and pulling the results back out, is a plain authenticated HTTP call, which means it can be scripted, scheduled, or wired into whatever else a team already uses to manage its work.

That also means a scan can be triggered by something else entirely, a ticket being opened, a new host showing up in an inventory system, a nightly cron job, rather than by a person remembering to click start. The scan still runs the same recon, verification and scoring it always does; only the trigger changes.

How do you create and track a scan through the API?

A `POST` to the jobs endpoint creates a background scan, and `GET` requests against the same path list every job or return the status of one specific job by its ID. A job can be cancelled mid-run with its own cancel endpoint, which matters when a target turns out to be out of scope or a scan needs to stop for any other reason before it finishes.

Once a scan completes, it shows up in the scans list, and its full data is available from its own endpoint. From there, an HTML report can be pulled directly, and a scan's discovered assets are available both as an enriched list and as a diff against a previous scan of the same target, which is the piece that matters most for anyone tracking a target's attack surface over time rather than looking at a single point-in-time snapshot.

What can you do with individual assets and findings?

Two endpoints work on a specific host inside a scan rather than the scan as a whole. One triggers takeover verification against that host, confirming whether a discovered subdomain or asset is actually vulnerable to takeover rather than just flagged as a candidate. The other requests an AI-generated insight on that specific asset, when AI triage is configured, folding a natural-language read of the asset into the same API surface as everything else.

A separate group of endpoints, covering attack-path graphing, credentials, network and cloud findings, Active Directory data, out-of-band results, re-verification, intercepted traffic, metrics and timeline data, exposes the deeper autonomous-testing output the same way, so a team building its own dashboard or pipeline is not limited to summary-level data.

That level of access is what makes a custom internal dashboard practical in the first place. A team that already tracks findings in its own ticketing system, for example, can pull structured data straight from these endpoints instead of re-typing what a report already says.

What else does the API expose?

A small set of system endpoints round things out: a severity breakdown across findings, the current status of the bundled detection templates, an endpoint to force a template refresh, and a WebSocket connection for real-time updates as a scan progresses, which is what the dashboard itself uses to update live rather than polling. Health, login, account activation and initial setup are the only endpoints that do not require authentication; everything else does.

None of this replaces the CI/CD-facing SARIF and JUnit export Vexta already produces for pipelines. It is the layer underneath that: the API is how a team builds whatever workflow sits on top of Vexta, whether that is a custom dashboard, a scheduler, or a script that kicks off a scan the moment a new asset shows up somewhere else in their inventory. Endpoint availability can vary by license; see plans on the pricing page for specifics.

Key takeaways

What Vexta's REST API covers: