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

Telegram

Configure Telegram authentication while preserving Clawdbase account continuity.

Telegram login begins at /auth/telegram/start. Clawdbase start routes add a signed purpose, state and return target so the callback can store a provider connection or create a Page without replacing the active session.

Configuration checklist

  • Telegram Client ID and secret are present on the server.
  • The exact production callback is listed in Telegram's Login Widget/OpenID settings.
  • Local callback URLs are separately allowlisted when local testing is required.
  • Apex and www hosts are not mixed between the outgoing request and provider configuration.
  • State and nonce are validated and expired flows are rejected.

Scope of proof

Telegram account authentication proves that account. Channel administrator status and bot control require their own provider-native checks before creating those canonical Pages.

Canonical callback

https://clawdbase.ai/auth/telegram/callback

TELEGRAM_LOGIN_REDIRECT_URI must equal the URI registered for the Telegram Login/OpenID application. Register separate localhost entries when provider settings support development callbacks; do not send a production callback from a local start request by accident.

Authorization Code with PKCE

The start route generates verifier, S256 challenge, state and nonce and stores them in HttpOnly SameSite cookies for ten minutes. The callback exchanges the code with HTTP Basic client authentication, validates Telegram's signed ID token with JWKS and checks issuer, audience, expiry and nonce.

Purpose-bound callback

The Telegram callback also reads the Clawdbase add-page/connection intent. When present, it attaches the identity to the original authenticated user and returns to the intended Console or registration surface. Primary Telegram sign-in behavior is skipped for this flow.

Data handling

The canonical Telegram subject, current username, display name and verification time can be stored in the provider connection and Page records. ID/access tokens, phone numbers and complete claims remain private and are not returned to public Pages.

Troubleshooting commands

Inspect the outgoing authorization URL in development and decode only the redirect_uri for comparison. Do not paste the full URL into public logs because it contains state, nonce and PKCE challenge. A corrected redirect setting requires starting a new flow.

Channels and bots

Keep unsupported Page kinds unavailable. A personal OpenID login cannot be upgraded into channel or bot ownership through a text field. Add separate administrator or bot-control verification before enabling those options.