# 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

```sh
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