Direct API Access

Identity infrastructure for the Agentic Web

USERNAME.md gives every handle a machine-resolvable, cryptographically verifiable identity — profiles, did:web documents, signed claims, and agent handshake surfaces. When your product needs to resolve, verify, or provision identity at scale, you talk to the API directly.

Request access Read the API docs

Looking for /api/reserved-handles.json?

The public bulk-roster endpoint has been retired — enumerating reserved handles exposed customer data, so it no longer ships a list. To check a single handle, use GET /api/availability/{handle} (public, no key). To resolve, verify, or provision identity programmatically at volume, that's what this page is about: supported, metered, signed API access with a contract behind it.

What you can build on

Every surface below is live today and documented in the OpenAPI spec. All of it is programmable.

GET /v1/users/{handle}/profile

Content-negotiated profiles

One handle, many representations — HTML, Markdown, JSON, JSON-LD, or a signed JWS bundle, selected by Accept header. Resolve a person or an agent by name.

did:web + .well-known

Decentralized identifiers

Each handle publishes a did:web document and the well-known documents agents use to discover and verify it — plain JSON over HTTPS, no proprietary resolver.

GET/POST /v1/users/{handle}/claims

Signed verifiable claims

Statements about a handle ("owns this domain", "controls this GitHub account") issued as Verifiable Credentials (JWS, vc+jwt) under the handle's Ed25519 key.

verifications/dns-txt

Domain-ownership proofs

Prove control of an external domain via a DNS TXT challenge, then mint a signed claim from it — a programmable trust primitive for your onboarding flows.

/v1/users/{handle}/atproto

ATProto / Bluesky binding

Bind a Bluesky DID so @you.username.md resolves natively across the ATProto network. Federated identity without running your own PDS.

import/keybase · keybase/verify

Keybase & PGP import

Import an existing Keybase identity — profile, social proofs, PGP key — and re-verify the proofs under the platform's own signed claims. Migrate trust, don't rebuild it.

Verifiable, not just available

Every API response is signed with the platform Ed25519 key (RFC 9421). You can prove a response came from USERNAME.md without trusting the transport.

$ curl -sD- https://username.md/v1/users/chris/profile \ -H 'Accept: application/json' HTTP/2 200 content-type: application/json content-digest: sha-256=:U9v...=: signature-input: sig1=("@method" "content-digest");keyid="platform-ed25519" signature: sig1=:MEUCIQD...: # verify against the published JWKS — no shared secret, no trust-on-first-use $ curl -s https://username.md/.well-known/http-message-signatures-directory

What "Enterprise" adds

The public API is free to read per-handle. Enterprise is for teams doing this at volume, with a contract, an SLA, and a name to call.

throughput

Metered, high-volume resolution

Rate limits sized to your traffic, with usage-based pricing instead of per-handle friction. Resolve millions of lookups without tripping the public quotas.

provisioning

Bulk handle reservation

Reserve and manage handles for your org, your users, or your fleet of agents programmatically — namespace allocation, not one-at-a-time checkout.

availability

Multi-region high availability

The platform runs multi-region and highly available on managed, RDS-backed infrastructure. Enterprise agreements attach uptime and support SLAs to it.

byo-domain

Bring your own domain

Delegate id.yourcompany.com to the platform via CNAME so identity resolves under your brand while we run the resolver, signing keys, and uptime.

assurance

Signed-response guarantees

Ed25519 signing on every response, published verification keys, and key-rotation notice — so your compliance story for "was this identity data authentic?" is cryptographic.

support

Priority support & DPA

A direct line, onboarding help, and a Data Processing Agreement. Built and operated by The Holding Company.

The surface, at a glance

Public reads need no credentials. Owner and provisioning operations use a Bearer API token. Full reference in the OpenAPI spec and developer guide.

EndpointWhat it doesAuth
GET /api/availability/{handle}Is a handle available / taken / reservedPublic
GET /v1/users/{handle}/profileContent-negotiated public profilePublic
GET /v1/users/{handle}/preferencesTheme / accent presentation prefsPublic
GET /v1/users/{handle}/claimsSigned verifiable-claim bundlePublic
POST /v1/users/{handle}/claimsIssue a signed claimBearer
POST /v1/users/{handle}/verifications/dns-txtStart a domain-ownership challengeBearer
POST /v1/users/{handle}/atprotoBind a Bluesky/ATProto DIDBearer
POST /v1/users/{handle}/import/keybaseImport + re-verify a Keybase identityBearer
GET /.well-known/…did:web, handshake, JWKS signing keysPublic

Let's make it official.

Tell us what you're building and the volume you expect. We'll scope access, limits, and an agreement — usually within a business day.

Email [email protected] Explore the docs first