Preview — not for production reliance
Agentic Root TrustPowered by Sectigo
Documentation

Docs For organizations

Claiming a domain

File a claim, publish the DNS TXT challenge at _workload-directory.<domain>, run the check, and keep domain control fresh with the 90-day recheck.

A claim is your organization's request to be recorded as the operator of one exact domain. Domain control is the first of the three checks; the claim then waits for identity and authority review.

The three checks behind a verified claim A claim passes three checks in order. One, domain control: a single-use token in a DNS TXT record at _workload-directory.domain, seen by both Cloudflare and Google DNS and rechecked every 90 days; the claim is pending_domain. Two, organization identity: a reviewer checks legal name, jurisdiction and registration; pending_identity. Three, representative authority: confirmed through an independently sourced contact, approval expires within a year; pending_authority. Then the claim is verified and can authorize issuers. At any step a claim can need more information, be rejected or be disputed. 1 Domain control single-use token in DNS TXT _workload-directory.<domain> seen by Cloudflare + Google rechecked every 90 days 2 Organization identity a reviewer checks legal name, jurisdiction, registration a DV certificate alone is never enough 3 Representative authority confirmed through an independent contact names the permitted actions; expires within a year Verified can authorize issuers pending_domain pending_identity pending_authority verified At any step a claim can become needs_information, rejected or disputed. Conflicting claims go to review, never first come, first served.
Your claim passes three checks. This page covers the first; reviewers handle the other two.

Domain not listed yet?

You can add an exact name before claiming it. The directory adds it only if it resolves in public DNS and serves a certificate from a publicly trusted CA.

Adding a domain that is not listed yet A search finds no record for newco.ai. A signed-in user chooses Add this domain, for that exact name only. The directory checks automatically that the name resolves in public DNS and serves an HTTPS certificate that chains to a publicly trusted root. If both pass, the domain is listed as unclaimed with no popularity rank and can then be claimed through the three checks. If either fails, nothing is added. Search newco.ai no record yet Add this domain signed-in user exact name only Automatic checks ✓ resolves in public DNS ✓ HTTPS certificate chains to a publicly trusted root Listed unclaimed, no rank Claim it the three checks either check fails refused: nothing is added Adding a name never adds its parent or any other name.
Adding an unlisted domain: automatic checks first, then the normal claim.

File a claim

From the console, choose Claim a domain on your organization's page, or start from the domain's public record. Through the API:

bash
curl https://svid.io/v1/claims \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Origin: https://svid.io" \
  -H "Cookie: __Host-art_session=<session>" \
  -H "x-art-csrf: <csrf_token>" \
  -H "Idempotency-Key: claim-payments-example-com-1" \
  -d '{"organization_id":"org_7k3m9q2x8d5f1h4j6n0p2r4t8v","domain":"payments.example.com"}'

An owner or domain administrator can file a claim, with a session or a service token. A domain the directory does not know yet is added as unclaimed. Limits: one open claim per organization per domain (409), and at most 10 new claims per organization in a rolling hour (429).

The claim covers the name you challenge and nothing else. Control of payments.example.com says nothing about example.com, and a subdomain of someone else's verified domain needs a delegation from them.

Publish the TXT record

The response carries the first DNS challenge:

json
{
  "dns_name": "_workload-directory.payments.example.com",
  "record_type": "TXT",
  "value": "art-verify=<token>",
  "expires_at": "2026-10-06T12:00:00.000Z",
  "max_attempts": 5
}

Add a TXT record at dns_name whose content is exactly value. Copy it now: the value is shown once, and an idempotent replay of the request returns value: null with value_redacted: true. The directory stores only a hash of the token.

  • Publish at that exact name, not through an alias. An answer reached through a CNAME or DNAME never counts, and the check fails with cname_not_allowed. If _workload-directory.<domain> is an alias today, remove the alias and add the TXT record directly.
  • Both resolvers must see it. The check queries Cloudflare (cloudflare-dns.com) and Google (dns.google) public DNS over HTTPS. If either does not return the record yet, the result is txt_not_found with the resolver's name. Wait for your DNS TTL and try again.
  • A challenge is valid for 24 hours and allows 5 checks.

Run the check

bash
curl https://svid.io/v1/claims/<claim id>/verify -X POST \
  -H "Origin: https://svid.io" -H "Cookie: __Host-art_session=<session>" -H "x-art-csrf: <csrf_token>" \
  -H "Idempotency-Key: verify-1" -H "Content-Type: application/json" -d '{}'

The answer is 202 with a job; poll GET /v1/jobs/<job id> until it finishes. The console does this for you. While a check of the same attempt is queued or running, the same job is returned.

The challenge is bound to the account that requested it, the organization, the domain and the claim. Another member of your organization cannot finish your challenge (wrong_account), and calling verify with no live challenge of your own answers 422 semantic_check_failed.

If the value is lost, the challenge expired or its attempts ran out, issue a new one with POST /v1/claims/{id}/challenges. Each claim gets at most 5 challenges in total. When the last one fails and nothing else is live, the claim expires.

When the record matches at both resolvers, the challenge is consumed, dns_challenge evidence is recorded and the claim moves to pending_identity. Continue with evidence and review.

Claim states

State Meaning
pending_domain Waiting for the DNS challenge
pending_identity Waiting for organization identity review
pending_authority Waiting for representative authority review
verified All three checks passed
needs_information A reviewer asked for more evidence
rejected A reviewer rejected the claim; it can be appealed
disputed Competing claims or an appeal are under review
suspended Domain control lapsed, the authority expired, or a reviewer suspended it
expired, withdrawn Terminal

Competing claims on the same domain are sent to review; they are never decided by whoever proved DNS first.

Keep domain control fresh: the 90-day recheck

A verified claim must prove domain control again every 90 days. The recheck does not disturb a verified organization:

  1. 76 days after domain control was last proven, the directory issues a recheck challenge valid for 14 days. Nothing changes in the meantime.
  2. An owner or domain administrator reveals it with POST /v1/claims/{id}/recheck-challenge (the console shows it on the claim page). Each reveal rotates the token, so the previous value stops working, and the value is bound to the person who revealed it. Reveals are limited per person and per claim within the 14-day window.
  3. Publish the new value at the same _workload-directory.<domain> name and call POST /v1/claims/{id}/verify as before.

If 90 days pass without a passed recheck, the claim becomes suspended and the issuers it backs stop resolving. Passing the recheck restores it, as long as the identity and authority evidence have not expired. A binding left suspended for more than 30 days is withdrawn for good; see suspension.

Withdraw or appeal

  • Withdraw: POST /v1/claims/{id}/withdraw with expected_version. Owner only, with step-up. It is terminal, and a verified claim's issuer bindings stop resolving in the same commit.
  • Appeal: a rejected claim can be appealed by an owner with step-up (POST /v1/claims/{id}/appeal), at most 3 times. It moves to disputed for a reviewer. Appealing does not bring back bindings that were withdrawn.