A real-time verification endpoint for STI testing credentials. One API call with a user's share token returns the verification status, panel, issuer, and recommended-retest date. Auto-expiration means a verified result is always current. Sandbox is free; paid tiers from $499/mo with optional BAA.
One API call. Pass your API key in the X-API-Key header. Returns live verification status that auto-expires when the user is due for retest — so a verified badge always means something current.
Apply for an API key below. Pass it in the X-API-Key header with every request.
/api/v1/verify| Parameter | Required | Description |
|---|---|---|
token | Yes | Public URL token from the user's TestedClear link |
format | No | json (default) or badge (HTML embed) |
All non-error responses return verified as a boolean — that is the only field you need to gate access on. Treat any non-200 status (other than 404) as a transient failure and retry.
Errors are returned as JSON with an error field and the status code in the HTTP response.
Every error response includes docs and apply URLs so that unfamiliar consumers of the API get pointed to the right place.
verified: false automatically when the user's recommended retest date passes — no action needed from you or the user. A verified badge always means currently within testing window.Usage is metered per-month per-key. Each successful call counts as one unit. Calls that return 4xx errors do not count against usage.
Sandbox is capped — once you hit 1,000 calls in a month, the endpoint returns 429 until the 1st of next month. Paid tiers allow overage and bill automatically through Stripe.
The simplest integration — an iframe that renders a small verified badge. Uses format=badge on the standard verify endpoint and counts toward your monthly call quota.
For integrations that want richer badge options (SVG, HTML with display name, JSON for native rendering), use the dedicated Badge Display endpoint. Requires a tc_badge_ key — a separate key class from the verify-API tc_live_ key.
/api/v1/badge| Parameter | Required | Description |
|---|---|---|
token | Yes | Public URL token from the user's TestedClear link |
format | No | json (default), html, or svg |
The JSON response includes display_name when the user has set one — useful for rendering a personalized badge alongside a user's profile.
For apps that want verification status tied to a specific TestedClear user account (rather than a shareable link), use the OAuth 2.0 authorization code flow. The user consents in their TestedClear account, your app receives a long-lived access token, and you can then check verification status without the user ever sharing a link with you.
OAuth is a separate integration pathway — contact rob@testedclear.com to onboard as a partner and receive a client_id and client_secret.
The redirect_uri must exactly match one of the URIs registered with your partnership. After the user consents, they're redirected back with ?code=...&state=... appended.
Auth codes expire after 10 minutes and are one-shot — they can only be exchanged once. Store the resulting access_token securely on your server.
The OAuth endpoint returns the same verification shape as the verify API but tied to the user who consented — no token-sharing required. Same auto-expiration semantics apply.
We work with dating apps on deeper integrations — native badge display, user auth flows, and co-branded verification experiences.