Issues are convenient to look at with your own eyes, but fixing them is a programmer’s job. So that you do not have to retell the list by hand, the product has a separate entrance for programs: with an access key, a coding agent picks up issues, reads the evidence, fixes the code and marks what was repaired. Below is what is available and how not to shoot yourself in the foot with the key.
Why this is needed
Test Agent finds problems but does not fix the site — that is the job of whoever writes the code. The loop closes when the fixer is also a program: the check then reports the breakage by itself, the repair arrives, and the next run confirms the result. This is how pairings with coding agents work — Xedant Agent, for example.
What the key unlocks
- The issue list — with filtering by project and status.
- An issue’s card — everything you see yourself: the snapshot, the element, the message, the history, the repeat count. The snapshot is also available as a separate link.
- Status changes — resolve an issue or reopen it.
- The screen report — the page’s whole history: comments, checks, screen types. Handy when it is not one error that needs sorting out but an entire page.
- Everything else the interface can do — projects, screens, rules, actions, tests, runs, schedules and build triage. The visual part goes as its own family: builds, snapshots, comparisons, baselines, the “awaiting decision” list, share links and reading visual settings.
- Scripts — the project’s script list with execution-environment facts, reading one script with its code, writing (the code and the manifest entry are saved together), deleting, the run journal with filters, and a trial run with arguments and data you pass. Deleting a script that is in use is refused, with a list of what references it.
An example request — just to show this is an ordinary text call, not some special contraption:
curl -H "X-API-Key: KEY" https://your-server/api/ext/issues?project=shop&status=openLong-lived keys
Besides the key from the server settings there are long-lived keys. Such a key is issued in the interface, shown once and passed in the Authorization: Bearer taj_… header instead of X-API-Key. It fits the places where an environment key is awkward: a CI build, a command line, an external model client.
A key has one of two permissions: “readonly — read and flag” — reading and marking, or “full — read and write” — changing things too. Revocation is instant: everyone who used the key stops passing authentication at once. Details — in the API Keys section.
What happens without the key
When the key is not set, these addresses answer “not configured” — the access is simply off. With a wrong key — refused. Sign-in by login and password does not work here at all: these are different access paths, and a browser session is not for programs. That is by design: external access exists for machines, and it has its own door.
The working cycle
- The coding agent picks up a project’s open issues.
- For each one it reads the evidence: the message, the element, the snapshot — and understands what broke.
- It fixes the site’s code and marks the issue resolved.
- The next run checks the same spot and confirms the issue is gone.
When the fix did not help, the issue reopens by itself — this is where the product closes the loop and keeps an “fixed” report from deceiving it.
Scripts over the key
A script is a file with Python code that a project uses to extend itself (details — on the Scripts & Extensibility page). Over the key, everything you can do by hand on the “Scripts” tab is available: look at the roster, read and write the code, delete, browse the run journal and give a script a trial run.
The project’s script list arrives with the execution environment’s state: whether Python is there, whether the environment is ready, what the last installation error was, how many runs and failures in the last 24 hours.
curl -H "X-API-Key: KEY" https://your-server/api/ext/projects/shop/scriptsWriting a script is one request: the title, the “what it is for” note, its own timeout, variables and the code. The code and the manifest entry are saved together. Values with “secret” names are read back masked; to keep the already-saved value, send the mask back.
curl -X PUT -H "X-API-Key: KEY" -H "Content-Type: application/json" \
-d '{"title":"Check /health","notes":"Watches the /health address contract",
"timeoutSec":30,"env":{"API_TOKEN":"$MY_KEY"},
"code":"import json, sys\ndata = json.load(sys.stdin)\nprint(json.dumps({\"ok\": True}))"}' \
https://your-server/api/ext/projects/shop/scripts/check-api-healthDeleting removes both the file and the manifest entry. When something references the script — a test step, a comparison engine, a classifier or a finished-run hook — the product refuses and lists the references: untie them first.
curl -X DELETE -H "X-API-Key: KEY" https://your-server/api/ext/projects/shop/scripts/check-api-healthThe run journal is read with filters by status, pipeline point and time; fresh records come first.
curl -H "X-API-Key: KEY" "https://your-server/api/ext/projects/shop/scripts/check-api-health/runs?status=error&pageSize=50"A trial run executes at once, with the arguments and data you pass. A successful run returns the journal record and what the script printed; a failed one answers with an error carrying the failure kind and the journal record number.
curl -X POST -H "X-API-Key: KEY" -H "Content-Type: application/json" \
-d '{"args":{"min":5},"payload":{"url":"https://api.example.com/health"}}' \
https://your-server/api/ext/projects/shop/scripts/check-api-health/testThe built-in manual at GET /api/ext also has a scripts section: the run contract, variables, restrictions and failure kinds. The “machine approval is impossible” rule holds here too: a script’s answer never approves a baseline.
The key is like a password
The access key can be viewed and copied in Settings → UI Testing — the same one the Chrome addon uses. Treat it as a password: it opens the issue list and the page snapshots. Hand it only to those who really should see this data, and never post it in public places.
And one honest limitation: a baseline cannot be approved through external access. No key, with any permission, can accept a visual difference — the decision always stays with a human in the browser. That is deliberate: approval changes what all future builds compare against.
The MCP tools work over the same key: there are nine of them, and they close the visual cycle — run a build, get the “awaiting decision” list, look at a difference, re-compare, propose a decision for a group, start a test healing, publish evidence, get help. They cannot approve a baseline either. How this is arranged — in the Live Page & MCP section.
And for a CI build there is a ready command-line tool, viz: it starts a build and waits for the result, answering with exit code 0 — pass, 7 — a human decision required, 8 — fail. It approves nothing: it simply has no “approve” command. Details — in the CI & Notifications section.
Next: how the agent repairs broken checks by itself — in the Auto-Fix section.