Application API

The register application currently uses versioned endpoints under /api/v1. These endpoints support the official application and are not yet a general-purpose public developer API or a stability commitment for third-party integrations.

For the planned public integration surface, see Web3 Name API.

Name availability

GET /api/v1/names/check/:name

Returns normalized availability information. Product states include ordinary availability, registered or reclaimable names, protected external namespaces, and protected wallet identifiers.

Reservations

POST /api/v1/reservations

Requires an authenticated register session. The server derives the wallet and normalized name and enforces active-reservation uniqueness.

Reservation payment

POST /api/v1/reservations/:id/payment-intent
POST /api/v1/reservations/:id/payment-submit
GET  /api/v1/reservations/:id/payment-status

The submit endpoint records a candidate transaction hash. Confirmation occurs only after independent receipt and event verification.

Minting

POST /api/v1/reservations/:id/mint-authorization
POST /api/v1/reservations/:id/mint-submit
GET  /api/v1/reservations/:id/mint-status

Profile and records

GET  /api/v1/reservations/:id/profile
POST /api/v1/reservations/:id/profile

Lets the reservation's owner read and publish a draft profile (avatar, description, social handles, and address records) before it becomes a signed, public resolver record. Requires the same authenticated register session as the endpoints above.

Do not build a production integration against undocumented application endpoints. A public schema, authentication model, rate limits, compatibility policy, and supported origin will be published with the developer API.

Authentication and errors

Sensitive endpoints require the register session cookie. Clients should handle 400, 401, 403, 404, 409, 429, and 5xx responses distinctly. A retryable transport failure must not be interpreted as a rejected payment or mint.