---
title: "Get Verified Badge"
method: GET
path: "/api/v1/badges/run/{run_id}/verified.svg"
tags: ["badges"]
---

# Get Verified Badge

`GET /api/v1/badges/run/{run_id}/verified.svg`

## Request

- Base URL: `https://api.badgeia.com`
- URL: `https://api.badgeia.com/api/v1/badges/run/{run_id}/verified.svg`
- Auth: none declared

SVG verified-state badge for a single run — the embeddable credential.

Honest by construction:
  * verification flag off, unknown/private run, or unsigned run →
    neutral "Unverified" badge (never a green ✓ for something we
    can't vouch for).
  * simulated run → amber "◐ Simulated".
  * signed real-execution run → green "✓ Verified".

Visibility: a private run renders the same neutral "Unverified" badge
as an unknown id, so the embed never leaks that a private run exists
(AC-04 / CLAUDE.md rule #8).

BRIEF-RES-014-A §5 / AC-07 — this is the ONE place we can observe a
verified card being rendered on an EXTERNAL surface (a README, a blog).
Every render fires `verified_embed_viewed` server-side, tagged with the
`referrer` (the embedding site) and the `verified_state`, so the embed →
/verify → signup loop is measurable. The cache header (max-age=300) means
a busy README won't fire on every page-load, only ~once per 5 min per CDN
edge — which is the right granularity (placement count, not raw hits).

## Path parameters

- `run_id` string, required

## Query parameters

- `style` string

## Response `200`

Successful Response

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/badgeia/apis/badge.md) · [All operations](https://skmtc.dev/badgeia/apis/badge/llms.txt) · [OpenAPI document](https://skmtc.dev/badgeia/apis/badge/revisions/7e7f7fee8b77?raw)