Skip to main content

Starting the Server

The server listens on 0.0.0.0:9002 by default.

CORS Configuration

The server’s CORS behavior is controlled by cors_allowed_origins in ~/.vigolium/vigolium-configs.yaml:

Project Scoping

All server operations are scoped to a project via the X-Project-UUID request header. If omitted, the default project is used.
All queries (findings, HTTP records, stats, scans) return data scoped to the project specified in the header. See Projects for the full multi-tenancy reference.

Authentication

All API requests (except /health) require a Bearer token:
API key resolution order: VIGOLIUM_API_KEY env var > server.auth_api_key in config file.

API Endpoints

Ingesting Data via API

The /api/ingest-http endpoint accepts multiple input modes. All requests use POST with a JSON body.

Ingest a Single URL

Ingest Multiple URLs (url_file mode)

Pass a newline-separated list of URLs. Lines starting with # are treated as comments.

Ingest a curl Command

Using content_base64 to avoid JSON escaping issues:

Ingest a Raw HTTP Request (Burp-style)

Send a base64-encoded raw HTTP request, optionally with its response:
With both request and response:

Ingest a Raw HTTP Request with a URL Hint

Raw HTTP requests don’t contain the scheme (https vs http), and the Host header may not match the public hostname (e.g. behind a load balancer). Use the url field to provide the correct scheme and host:

Ingest an OpenAPI / Swagger Spec

Using base64 for larger specs:

Ingest a Postman Collection

Ingesting Data via CLI

The vigolium ingest command supports both remote (server) and local (direct-to-database) modes.

Remote Ingestion (to a running server)

Local Ingestion (direct to database)

When --server is omitted, requests are fetched and stored directly in the local database:

Ingesting via Transparent Proxy

Start the server with a proxy port to passively record HTTP traffic:
Then route your tools through the proxy:
All proxied HTTP traffic is automatically recorded in the database. HTTPS CONNECT tunneling is passed through without recording.

Querying Ingested Data

List HTTP Records

List Findings

Server Info

Response:

Scan Management via API

After ingesting HTTP records, trigger a vulnerability scan via the API.

Trigger a Scan

Force re-scan with specific modules:
Returns 202 Accepted on success, 409 Conflict if a scan is already running.

Check Scan Status

Cancel a Running Scan

See the API Reference for full request/response details.

Running AI Agents via API

The agent API provides four run modes that mirror the vigolium agent CLI subcommands (query, autopilot, swarm, audit). Concurrency is controlled by server.agent_heavy_max and server.agent_light_max.

Query, Single-Shot Agent Run

At least one of prompt_template, prompt_file, or prompt is required. Returns 202 Accepted on success. Set "stream": true for real-time SSE output. The legacy repo_path JSON field is still accepted as an alias for source.

Autopilot, Autonomous Scanning

Swarm, AI-Guided Multi-Phase Scan

SSE events are data: lines with JSON payloads: {"type":"chunk","text":"..."} for real-time output, {"type":"phase","phase":"..."} for swarm phase transitions, {"type":"done","result":{...}} on completion, or {"type":"error","error":"..."} on failure.
Provider overrides are CLI-only. The server resolves the olium provider once from agent.olium.* in vigolium-configs.yaml. To switch providers on a server-side workload, edit the YAML and reload, there is no per-request provider field.

List All Agent Runs

Check Agent Run Status

Once the run completes, the response includes a result field with the full agent output (raw text, findings, HTTP records). See Agent Mode for the full agent documentation (autopilot, swarm, audit, piolium, query, olium) and the API Reference for request/response details.

Input Modes Reference

For burp_base64 mode, you can also include http_response_base64 to store the response alongside the request. For modes that accept large payloads, prefer content_base64 to avoid JSON escaping issues.