Developer overview
Put Clawdbase trust evidence at the decision point in your software.
Clawdbase exposes six canonical trust operations through one authenticated, metered backend. The Developer Access playground uses the same route and billing state as an external integration.
Activation path
- 1Sign up or connect GitHub
- 2Creator identity / Page prepared
- 3Create an Access Key
- 4Run the first Agent T&C operation
- 5Core activation complete
- 6Connect X or Telegram (optional)
- 7Register authorized Agent or Skill repositories (optional)
Returns Trust and Confidence outputs for a registered Agent.
agent_scoreReturns Trust and Confidence outputs for a registered Skill.
skill_scoreReturns lineage, associated creator identity and Creator T&C Score.
agent_skill_lineageReturns Trust and Confidence outputs for a creator identity.
creator_scoreReturns Trust and Confidence outputs for an X account.
x_account_scoreReturns Trust and Confidence outputs for a Telegram account, channel or bot.
telegram_account_scoreIntegration lifecycle
- 1Create a scoped Access Key
- 2Choose the canonical operation
- 3Send subject and idempotency key
- 4Read result and scoring context
- 5Apply your decision policy
Delivery channels
The operation route validates channel as api or mcp, but only api reaches reservation — channel: "mcp" is rejected with mcp_not_available before any credits are checked or charged. A public MCP transport should only be documented as available after a deployed MCP endpoint and tool discovery have been verified.
Quickstart
Create a key and run agent_score.
REST API
Request and response contract for the live operation route.
Errors
Handle authorization, balance and upstream failures.
Usage ledger
Understand reservation, settlement and charge source.
Choose an operation
| Decision | Operation | Subject example |
|---|---|---|
| Evaluate an Agent before delegation | agent_score | owner/repository or canonical Agent ID |
| Evaluate a Skill before installation | skill_score | owner/repository or canonical Skill ID |
| Inspect the builder behind an artifact | creator_score | GitHub handle or Creator identity |
| Inspect upstream and Creator context | agent_skill_lineage | Agent or Skill subject |
| Evaluate an X communication identity | x_account_score | @handle or resolvable X subject |
| Evaluate a Telegram identity | telegram_account_score | account, channel or bot subject |
Server integration pattern
Create one key per workload
Separate development, CI and production credentials. Give each only the scopes it needs and set an expiry where operationally practical.
Persist request identity
Generate an idempotency key when the logical job is created and store it with the job. Retries reuse that value.
Call from trusted code
Send the Access Key only from a server, worker or protected automation environment. Browser and mobile clients call your backend instead.
Separate evidence from policy
Store the returned evidence and ledger ID, then evaluate it with a versioned policy that also considers permissions and impact.
Reliability model
The operation route validates authentication, operation, scope and inVerus configuration before reserving usage. It then reserves a balance atomically, calls inVerus with a bounded timeout and settles the ledger. Failed upstream calls reverse the reservation and return a ledger ID for correlation.
Compatibility
Treat response objects as additive. Preserve unknown inVerus fields when logging or storing the raw assessment, but only make product decisions from fields your integration explicitly supports. Pin your own policy version and test it against complete, partial, stale and unavailable evidence.
Continue with the Quickstart, then read Authentication, Idempotency, and Errors before production rollout.