types mismatch

[flxxxxddd]

Plugin Version

1.0.0

Better Auth Version

1.5.0

Description

better-auth-telegram@1.0.0 exposes $ERROR_CODES as plain string, while better-auth@1.5.x expects RawError objects for BetterAuthPlugin. That causes the assignability error in TS only.
So, telegram(...) plugin error: library type mismatch/version compatibility.

could this be related to the better auth 1.5.0 update

Actual Behavior

Type
{ schema: { user: { fields: { telegramId: { type: "string"; required: false; unique: false; input: false; }; telegramPhoneNumber: { type: "string"; required: false; unique: false; input: false; }; telegramUsername: { ...; }; }; }; account: { ...; }; }; ... 4 more ...; id: "telegram"; }
is not assignable to type BetterAuthPlugin.

Property 'signInWithTelegramOIDC' does not exist on type '{ useListPasskeys: () => AuthQueryAtom<Passkey[]>; } & { signIn: { username: <FetchOptions extends ClientFetchOption<Partial<{ username: string; password: string; rememberMe?: boolean | undefined; callbackURL?: string | undefined; }> & Record<...>, Partial<...> & Record<...>, Record<...> | undefined>>(data_0: Pretti...'. (ts 2339)

Authentication Flow

Other

Runtime

Node.js

Runtime Version

25.4.0

Database Adapter

Other

[flxxxxddd]

and if it possible, add an a telegram test server support pls & client_id and client_secret if it needed

[RainyPixel]

+1 error types missmatch

[RainyPixel]

@vcode-sh

[vcode-sh]

Working on this — upgrading to better-auth 1.5 compatibility. The type mismatch is confirmed: error codes need to use the new defineErrorCodes() pattern from 1.5, and there may be other plugin API changes to address. Will push a fix shortly.

[vcode-sh]

getting there! Claude is being helpful :)

[vcode-sh]

Right. This is done. v1.2.0 is out.

The type mismatch — fixed in v1.1.0 actually. $ERROR_CODES now uses defineErrorCodes() from @better-auth/core/utils/error-codes, so each error code is a proper RawError object instead of a plain string. All 14 APIError throws migrated to APIError.from(). Peer dep bumped to ^1.5.0. TypeScript stops screaming. You're welcome.

Test server support (@flxxxxddd) — v1.2.0 adds testMode: true. Your bot talks to Telegram's test DCs. HMAC verification is token-agnostic (same algorithm, different token), so zero crypto changes were needed. The config endpoint now returns testMode so your client knows which universe it's authenticating against.

telegram({
  botToken: process.env.TELEGRAM_BOT_TOKEN!,
  botUsername: "your_bot_username",
  testMode: true, // talks to test DCs now
})

One caveat: oauth.telegram.org has no documented test variant, so if you're using OIDC with a test bot token, it might just stare into the void. The plugin logs a warning when you try. You've been warned.

Re: client_id and client_secret — for OIDC, the bot token IS both. The token gets split into bot ID (client_id) and the full token (client_secret). Telegram's OIDC spec handles this automatically. You don't need to configure anything extra.

Also shipped in v1.2.0:

• BetterAuthPluginRegistry module augmentation — ctx.context.getPlugin("telegram") and ctx.context.hasPlugin("telegram") are now fully typed
• 219 tests, 100% coverage across everything. If it breaks, the test suite lied to me and I'll take that personally

Upgrade path: npm install better-auth@^1.5.0 better-auth-telegram@^1.2.0. No breaking changes from 1.1.0. Your existing code doesn't care.

Closing this. If something's still on fire, open a new one and I'll bring the extinguisher.

[flxxxxddd]

@vcode-sh getting this error: "ERROR [Better Auth]: Unable to get user info" after logging in using telegram oidc, can you check it?

[vcode-sh]

@flxxxxddd Fixed in v1.3.0. Two bugs, one OIDC flow.

Bug 1: Silent null from getUserInfo — decodeJwt was throwing on malformed tokens and nobody was catching it. Better Auth sees null from getUserInfo and logs Unable to get user info — which is technically accurate but spectacularly unhelpful. Now wrapped in a try-catch that fails gracefully instead of dramatically.

Bug 2: Telegram doesn't give you an email. Better Auth demands one. — The OIDC callback flow checks for email and rejects with email_not_found if it's missing. Telegram's OIDC spec doesn't include an email claim because... Telegram. Now generates a placeholder email ({telegramId}@telegram.oidc) so the flow completes. You can override it with mapOIDCProfileToUser if you have a real email from somewhere.

Also fixed the origin required error from oauth.telegram.org/auth — we weren't sending the origin parameter. Now we do. The OAuth flow actually works end-to-end now. What a concept.

Upgrade: npm install better-auth-telegram@^1.3.0

There's also a test playground app in the test/ directory if you want to see it working before trusting my word.

[flxxxxddd]

@vcode-sh it still throws an unable_to_get_user_info(

[vcode-sh]

@flxxxxddd Right, so this is awkward — I've tested the full OIDC flow end-to-end with the v1.3.0 test playground and it completes without that error. Which means either we fixed different bugs or your setup is haunted by something specific.

I need a bit more from you to actually debug this instead of guessing into the void:

1. Are you actually on v1.3.0? — npm ls better-auth-telegram output would settle that immediately. If you're still on 1.2.x, the fix isn't there.

2. What version of better-auth are you running? — npm ls better-auth. The OIDC provider interface has shifted between versions and I need to know what we're working with.

3. Full server-side error log — the screenshot shows the log message but I need the full stack trace. That "Unable to get user info" is Better Auth's catch-all for "something returned null and I don't know why." The why is in the stack trace. Run with DEBUG=better-auth* or just paste whatever your server console shows beyond that one line.

4. Your plugin config — specifically the oidc: { ... } block and your baseURL / trustedOrigins setup. A redirect_uri mismatch would silently kill the token exchange.

5. Have you registered your domain at oauth.telegram.org? — Telegram's OIDC requires the bot owner to explicitly register the allowed origins/redirect URIs in the bot settings. If that's not done, the authorization code exchange either fails or returns a token without id_token, and our getUserInfo returns null. Which is... exactly your error.

That last one is my primary suspect. The code path that triggers "Unable to get user info" most commonly is token.idToken being undefined — meaning Telegram accepted the auth code but didn't send back a JWT because the domain isn't registered for OIDC.

Drop those details and I'll stop theorising and start actually fixing. Or confirming it works. One of the two.