Page identifiers
Distinguish public slugs, database IDs and immutable provider identities.
| Identifier | Use | Mutable? |
|---|---|---|
| Public handle or repository slug | Human-readable routing and display | Yes |
| Clawdbase Page registration ID | Internal relation and API targeting | No |
| Provider account ID | Canonical X, Telegram or GitHub identity match | No |
| GitHub repository ID | Canonical Agent/Skill asset match | No |
| Canonical key | Provider-qualified uniqueness and locking | No |
Public routes may change when a handle or repository changes. The canonical record and ownership history should survive because matching uses immutable IDs.
Never expose provider access tokens, hashed Access Key material or service credentials as Page identifiers.
Canonical composition
The canonical uniqueness boundary includes provider, immutable provider/asset ID and, where the same asset can represent more than one product object, Page kind. For example, a GitHub repository selected as an Agent remains distinct from a Skill classification while repository rename does not create another Agent.
Route resolution
| Route | Lookup intent |
|---|---|
/a/{owner}/{repo} | Readable Agent repository lookup |
/a/id/{id} | Stable Agent ID lookup |
/s/{owner}/{repo} | Readable Skill repository lookup |
/s/id/{id} | Stable Skill ID lookup |
/c/{handle} | Creator presentation lookup backed by canonical identity |
/x/{handle} | X presentation lookup backed by immutable X user ID |
/tg-account/{handle} | Telegram presentation lookup backed by canonical Telegram ID |
Consumers should store the canonical Page ID returned by the API and use the returned public href for navigation. Reconstructing URLs from display names loses rename and normalization behavior.
Normalization
Handles are trimmed, leading @ is removed where appropriate, and comparisons use normalized case where provider semantics allow it. Repository owner/name pairs are presentation fields after an immutable repository ID is known. Do not apply one provider's normalization rules to another provider.
Duplicate repair
When duplicates are detected, support compares immutable provider IDs and canonical registration IDs first. The authoritative score and legitimate ownership relations are preserved; matching display labels alone never justifies merging Pages.
Identifier privacy
Provider IDs used for public resolution may still be treated as pseudonymous identifiers. Expose only those required for the product surface. Internal registration IDs, ownership IDs and connection IDs are opaque and must be authorization-checked before use in Console mutations.