vediqx

Use Vediqx from your agent

Two steps: make a key, then paste one setup into your agent.

  1. 1Make a key

    A key is shown once, when it is made. Put it in your environment as VEDIQX_API_KEY, never in a file you commit.

    Sign in to make a key here. Sign in

  2. 2Paste one setup

    Claude Code

    Run against the client itself

    Run it once in a terminal, in your project. The single quotes matter: .mcp.json then holds ${VEDIQX_API_KEY}, never the key, and Claude Code reads the variable when it starts. Start Claude Code from a shell where VEDIQX_API_KEY is set, approve the vediqx server when it asks, and /mcp lists it with five tools: check_app, get_report, list_apps, list_fixes and verify_fix.

    bash

    claude mcp add --transport http --scope project vediqx https://vediqx.com/api/mcp \
  --header 'Authorization: Bearer ${VEDIQX_API_KEY}'

What your agent can ask

check_app
Run Vediqx's outside check on a URL, the one a visitor's free check runs: it reads the app from the internet and never connects to its database. It returns an id, not a run id. The check takes a while: call get_report with the id until its status is finished. Its report never carries fixes or a link; checks of a database's rules and their fixes come from the checks Vediqx runs on a saved app.
get_report
The report for one check: its status, every finding with its tier, and what could not be checked with the sentence that would unlock each one, in structuredContent. For an id from check_app, fixes is empty and runId and reportUrl are null: that check is a visitor's. For a run id of a saved app's check, each fix carries its findingId and, when the fix is SQL, every statement of it; call verify_fix once one is applied.
list_apps
The apps this key's org has saved, with the id and the level each is connected at: the lowest reads the app from outside only, and the next also checks its database's rules as the app's own test accounts. Also the quickest way to confirm the key works.
list_fixes
The fixes from one of a saved app's runs, each with its findingId, its finding's fingerprint (the report's findings carry the same fingerprint and that id) and, when the fix is SQL, every statement of it, in structuredContent; a fix Vediqx could not prove safe carries no statements and says why in notShown; runs lists the app's newest runs. When the run looked from outside only, notChecked says what it did not look at, such as your tables' access rules, which need the Inside check. Without run_id it reads the newest whole run that finished. Until the app's address is proven, a run's details are locked: it says so, and an empty list then is not the same as nothing to fix. app_id comes from list_apps.
verify_fix
Re-check one finding after its fix is applied. A finding from an outside check re-runs for any organisation; one from a deeper check needs this organisation's deeper checks open, and until then is refused as beyond_level_0_closed with nothing re-run. When it runs it answers started; the verdict is shown on that finding's card in Vediqx and as a verify_fix run in list_fixes' runs, and the card closes only on a clean, controlled result. app_id comes from list_apps; finding_id is a fix's findingId in list_fixes.

The REST API

Send the key as Authorization: Bearer.

MethodPathWhat it does
POST/api/v1/checks

Starts a check of one address.

Body: { "url": "https://your-app.example.com" }

An id to read the report with. Hold on to it: it is the only way to open a check of an app you have not saved. This is the outside check a visitor's free check runs, so its report never carries fixes.

GET/api/v1/checks/:id

Reads a check: its status, its report and, for a run of an app you have saved, its fixes.

The same report the page shows, with no row values in it. Ask again until the status is finished.

GET/api/v1/apps

Lists the apps your organisation has saved.

Each app's id, name, address and level.

GET/api/v1/apps/:id/fixes

Reads the fixes from one of a saved app's runs: the newest whole run, or `?run=` one of its `runs`.

Each fix with its findingId and its finding's fingerprint (the report's findings carry the same fingerprint and that id), and the app's newest runs. When the run looked from outside only, notChecked says what it did not look at, in plain words. Until the app's address is proven a run's details are locked, and the answer says so in note: an empty list then is not the same as nothing to fix.

POST/api/v1/apps/:id/findings/:fid/verify

Re-checks one finding after a fix.

started once the re-check is under way; whether it is fixed lands on that finding's card in Vediqx, which closes only on a clean result with a control beside it. A finding from an outside check re-runs for any organisation; one from a deeper check is refused as beyond_level_0_closed until your organisation's deeper checks are open, and nothing is re-run.

When it says no

RefusalWhat it means
401 no_keyThis needs an API key. Create one in Settings, then send it as Authorization: Bearer wk_….
401 key_not_liveThat key is not in use any more. Create a new one in Settings; keys are shown once and cannot be read back.
403 not_this_orgs_appVediqx only looks inside a database for apps your own organisation has saved and connected. Save this app and connect it, then this works on it.
403 beyond_level_0_closedLooking inside your database is not open yet while Vediqx's own security review is finishing, so nothing was re-run and nothing was changed. This one is ours: it opens when that review lands, not from anything on your side.
404 not_foundWe could not find that on this key's organisation.
400 url_refusedThat address could not be checked. Send a plain https:// address with no username, password or token in it.
503 checks_pausedFree checks are paused right now, so nothing was started. Try again later; this one is ours.
503 oursSomething of ours was not ready, so nothing was started. Try again in a moment; this one is ours.

Limits

Checks per key, per day10
Checks of one host, per hour6
Runs of one saved app, per hour6

A check past a limit still starts, and comes back with nothing checked and a sentence saying which limit it met. Nothing is requested from your app, and the command line exits 2.

Command line exit codes

Exit codeWhat it means
0The check ran, read a whole report, and found nothing at or above --fail-on (default high), and nothing it could not check.
1The check ran and found something at or above --fail-on.
2Vediqx could not look: no key, a refusal, a timeout, an inconclusive or failed check, a report it could not read, or anything left unchecked.