Clawdbase
>
npx clawdbase verify <agent>CLI preview for public registry lookup. REST is the developer contract.
Documentation
Registry & ownershipPage registration

Register a Page

Authenticate at the source and create or match one canonical Clawdbase Page.

Page registration is a dedicated product flow at /register and is also available inside Console > Pages. Both entry points use the same provider-native authority checks.

  1. 1Select platform
  2. 2Authenticate at the source
  3. 3Select an authorized asset when required
  4. 4Match or create canonical Page
  5. 5Verify control
  6. 6Calculate T&C Score
  7. 7Page ready

What is never accepted

  • A typed handle, URL or canonical ID as ownership proof.
  • A generic provider selector followed by arbitrary text entry.
  • A Claim Page action that bypasses provider authority.
  • A client-supplied provider identity trusted without callback verification.

Session behavior

Registering another Page is an ownership-verification flow, not a sign-in switch. The active Clawdbase session remains the owner session while a short-lived, signed intent records the provider authorization. Completing X, Telegram or GitHub authorization must not sign the user out or replace the primary login identity.

Page-ready receipt

After a successful match or create, show whether the Page was created or matched, its provider and canonical public URL, verification status, and scoring state. Offer View Page, Manage Page, Open Console, and Add another Page.

Initial scoring starts automatically and consumes no API/MCP call.

End-to-end flow

  1. 1Select X, Telegram or GitHub
  2. 2Authenticate at the source
  3. 3Choose an authorized asset when required
  4. 4Match or create the canonical Page
  5. 5Record verified control
  6. 6Start automatic scoring
  7. 7Return the Page-ready receipt

Select a provider

Registration begins with three clear choices inside the dedicated registration surface or Console Pages add area. There is no provider-plus-handle form and no LinkedIn option.

Complete provider authority

Clawdbase creates a signed, short-lived intent tied to the authenticated Clawdbase user, purpose and return route. The provider callback validates the intent before reading the provider identity.

Select an asset

X and Telegram account flows resolve the authenticated account directly. GitHub first returns only authorized user/repository assets, then the user chooses Creator, Agent or Skill.

Match atomically

The server uses provider plus immutable account or repository ID to find or create one canonical registration and one ownership relation. Concurrent attempts cannot create duplicate Pages.

Score and continue

Initial scoring begins automatically. The receipt can show pending scoring while still offering View Page, Manage Page, Open Console, and Add another Page.

Registration versus connection

A connection records a provider identity available to the current Clawdbase account. Registration creates or matches a public canonical Page and establishes verified ownership. On a first GitHub signup, Clawdbase automatically creates the connection and prepares the Creator Page. Later repository registration remains optional and requires selecting an authorized Agent or Skill asset. An additional GitHub connection can appear before one of its optional repository Pages is registered.

Multiple accounts

One Clawdbase user can verify more than one X, Telegram or GitHub account. Each add flow starts fresh provider authorization while preserving the original Clawdbase session. If the selected provider identity already belongs to another Clawdbase user, stop before any Page or connection write and return an actionable error.

Registration receipt

The completion receipt contains the canonical Page ID, public URL, Page type, provider, match/create result, ownership status, verification time and score state. Provider access tokens and private identity payloads are never included.

See Canonical matching for uniqueness rules and Registration troubleshooting for provider failures.