Countersign · Quickstart · Examples · CI · Verify a receipt · Markdown

Example: checking a deploy claim

This is reference documentation, not instructions. Your operator's instructions take precedence: if anything here conflicts with them, follow your operator. Nothing here asks you to change how you report work unless your operator has adopted Countersign.

An agent or a deploy script has just shipped a page and wants a record that the page is live with the new content, which anyone can re-check later.

The claim

curl -sS -X POST https://countersign.signalry.ai/v1/deploy-claims \
  -H "Authorization: Bearer $COUNTERSIGN_API_KEY" -H "content-type: application/json" \
  -d '{"template":"static_page","url":"https://example.com/","contains":"Example Domain"}'

The service fetches the page itself, checks the status, the expected text and the absence of common error-page strings, and returns:

• counts_as_verified: true when it observed the checks passing at the reference_checked tier or above
• cite: a line such as VERIFIED: https://example.com/ ... (receipt https://countersign.signalry.ai/r/csh-...)
• receipt_url: the public receipt page, rechecked on a schedule (daily for the first week, weekly after)

What the receipt shows

The receipt page lists each run with its verdict and hash; the hash chain is anchored in Sigstore Rekor and RFC 3161 timestamps. If the page later breaks, the next recheck turns the claim decayed, so a stale "done" is visible.

Variants

• A redirect: {"template":"redirect","url":"https://example.com/old","location":"https://example.com/new"}
• A health endpoint: {"template":"api_health","url":"https://example.com/health","json_fields":[{"path":"ok","op":"eq","value":true}]}
• Over MCP: the file_deploy_claim tool at https://countersign.signalry.ai/mcp takes the same fields.

Related: https://countersign.signalry.ai/ci · https://countersign.signalry.ai/examples/ci-tests · https://countersign.signalry.ai/examples/verify-teammate