Visibility checks
Observe answers for saved customer questions.
Visibility runs saved questions against answer surfaces and records what actually appears: answer text, citations, and business mentions. Results are samples for later content planning, not rankings and not proof of why an engine answered that way.
In the dashboard
Open Visibility in the project sidebar, or go to /projects/visibility. With saved selected questions, one Run initial check action starts a bounded run over ChatGPT and Google AI Mode (two checks per question, up to ten selected questions). Progress shows answered, pending, and failed counts; each answer expands to full text, citations, and mention evidence with collection time. Absence in a captured answer is a valid observation. Failed checks are not zero visibility. Saving questions does not start a manual run; when a nonempty selection is first saved it attempts the initial check when configured, preserving explicit pause and existing runs. The page updates automatically while a run is active.
Included checks and recovery
Up to 20 question/engine checks are included per project per account-local day. Repeating the same question and engine that day returns its saved run; editing the question does not reset the allowance or rewrite the earlier answer. One run can be active per project. Starting again while it is active resumes that run, including after a queue interruption.
Cancel stops unsent checks. Already-submitted checks can finish and retain their results, including after the original developer key is revoked or the trial expires. Interrupted submissions without a saved receipt are marked uncertain and are never automatically purchased again. An unavailable check is not a negative visibility result.
Collection is bounded to 15 minutes and at most 12 processing rounds. Failed answers remain visible beside successful answers. Country/question mismatches are rejected; missing provider metadata stays uncertain. A requested locale is not proof that the provider used that language.
Read saved state
Examples use https://kitecraft.ai production. For local verification or a supplied preview origin, replace that origin with your configured KITECRAFT_API_URL, such as http://127.0.0.1:3100.
curl --fail-with-body "https://kitecraft.ai/api/v1/visibility/$PROJECT_ID" \
-H "Authorization: Bearer $KITECRAFT_API_KEY"Reads are free of provider calls and return run summaries with counts. A run detail returns per-question observations.
Start a check
curl --fail-with-body -X POST "https://kitecraft.ai/api/v1/visibility/$PROJECT_ID/start" \
-H "Authorization: Bearer $KITECRAFT_API_KEY" \
-H "Content-Type: application/json" \
-d '{}'start returns a run ID immediately without waiting. Poll status or the run endpoint until terminal; partial runs keep successful answers. Cancel stops further paid submissions. Starting paid work needs write access and an active trial or subscription. Cancellation requires write access but remains available after trial expiry.
CLI and MCP
kitecraft visibility status --id PROJECT_ID
kitecraft visibility start --id PROJECT_ID
kitecraft visibility run --id PROJECT_ID --run-id RUN_ID
kitecraft visibility observation --id PROJECT_ID --observation-id OBSERVATION_ID
kitecraft visibility cancel --id PROJECT_ID --run-id RUN_IDMCP tools mirror the same operations: visibility_status (read-only), visibility_start, visibility_run (read-only), visibility_observation (read-only), visibility_cancel. See CLI commands and MCP tools.
Daily checks
After you save a nonempty question selection, Kitecraft attempts the first visibility check automatically. Existing results and an explicit pause are preserved. Daily checks then use the same questions and the same included daily allowance. A manual check does not purchase a second copy of the same question and engine that day.
Use Daily checks on Visibility to pause or resume. Pausing stops work that has not been submitted; purchased answers can still arrive. Resume starts with the next account-local day, without buying missed days. The page distinguishes saved settings from an inactive environment. Recurring collection requires an enabled, configured scheduler.
The API exposes GET /api/v1/visibility/:id/daily and
POST /api/v1/visibility/:id/daily with {"enabled":false} or {"enabled":true}.
A status read never buys work. Settings writes require write access; enabling also
requires an active trial or subscription and a saved selection.
CLI: kitecraft visibility daily --id PROJECT_ID, visibility pause --id PROJECT_ID,
and visibility resume --id PROJECT_ID. MCP: visibility_daily_status and
visibility_daily_settings with the same project ID and enabled boolean.