The Trust API for Telegram: Querying Community-Level Reputation From Your Mini App (2026)

I've been thinking about this post for a while, and the timing finally feels right.

Telegram is in the middle of becoming an economic platform. Not a chat app with shopping bolted on — an actual economic substrate. 1 billion monthly active users. 500 million people using Mini Apps. $10B forecasted in-platform commerce by 2027. TON wallets. Telegram Stars. Paid channels. Paid Mini Apps. Subscription chats.

And every builder shipping into this economy hits the same problem: who are you actually transacting with? Is this user a real engaged community member, a fresh-account sybil, or a known bad actor? The Bot API answers basic facts — account age, premium status, global ban — but it doesn't answer the only question that matters in commerce: can I trust this person inside the Telegram social graph?

That's the gap we've been building Varta inside of. 48 protected communities, 29K+ members, 33 languages, ~30 spam detections a day, two years of cross-group ban signal accumulating. The Trust API exposes that signal to builders. This post is what it is, what it isn't, and how to be early.

Why a Trust API now

Three forces are converging.

First, Telegram became an economy. When the platform was free chat, trust didn't matter much — block and move on. Once people are paying, trust becomes the currency underneath the currency. Mini App developers need it. Paid community admins need it. Airdrop teams need it. Anyone running anything where signal-vs-noise translates to real money needs it.

Second, AI made cheap trust signals stop working. Aged accounts? Buyable in bulk. CAPTCHAs? Solved at fractions of a cent. Profile photos? AI-generated. Username uniqueness? Twenty look-alike variants per minute. The signals builders used to rely on — «this account is X months old, has a real photo, has posted before» — all of them are now affordable for adversaries to fake. Builders need higher-order signals; account-level no longer suffices.

Third, no central authority can solve this. Telegram itself focuses on platform-level integrity (global bans, basic anti-spam). Community-level trust — «is this person trusted in MY paid community under MY rules?» — is intentionally outside Telegram's scope. It needs to be built by infrastructure providers like Varta, sitting between the platform and the application. That's what the Trust API is: the missing middle layer.

What the Trust API answers

The single query that matters: given a Telegram user ID, what is this account's community-level trust profile?

The response is a structured profile, not a single number. Sample fields (subject to design-partner feedback):

• Trusted membership signal. Has this user been an active, non-flagged member of any Varta-protected community for more than 30 days? Quantitative score.
• Ban exposure. Has this user been banned for spam-like behavior in any Varta-protected community in the last 90 days? With ban category (income-scam funnel, image-spam, admin-impersonator pattern, etc.).
• Sender quality. Posting behavior patterns — coherent in-language, reply-heavy vs broadcast-heavy, content-relevance to claimed community type. Calibrated rather than binary.
• Language profile. What languages does this account post in? Helps detect sybils that claim to be English-speakers but post in a translated patterns.
• Account-age cross-check. Does the account's posting history match its claimed age? Sybils often have fresh accounts with «aged» metadata.
• Network co-occurrence. Has this user appeared alongside known sybils in suspicious clusters? Critical for airdrop sybil resistance.

Each query returns a structured JSON response. Each field is calibrated — the API tells you what it knows AND what it doesn't, so you can fall back to other signals when confidence is low.

How it works

The underlying signal comes from Varta's two years of operation as a moderation infrastructure across 48 communities.

Every time Varta makes a moderation decision — pass, delete, ban, ask-admin — that decision plus its category and confidence is written to a pseudonymized ledger. User IDs only. No message text. No group names. Just the structured outcome.

Over two years, that ledger accumulates into a network-level signal. A user banned in two paid communities for slow-funnel income scams is a known pattern. A user who's been an active, never-flagged member of four communities for 18 months is a known-trusted signal. A user with zero history anywhere is a fresh-account signal — sometimes legitimate, sometimes a sybil; the API tells you which alternative is more likely based on co-occurrence patterns.

The technical layer:

• Backend. EU-hosted (Hetzner Finland), GDPR-compliant, pseudonymized at write-time. The data store knows user IDs but does not know names, phone numbers, or off-platform identities.
• API. REST over HTTPS, JWT auth, JSON responses. Standard developer ergonomics.
• Rate limiting. Generous during beta (10,000 queries/day for design partners), tiered post-beta.
• Latency. Sub-200ms p95 target for the trust-profile lookup. Heavier endpoints (network-co-occurrence cluster analysis) are asynchronous.
• SLA. 99.5% during beta, 99.9% targeted for general availability.

Five use cases for builders

These are the use cases I've been talking to potential design partners about.

1. Mini App gating. Your Mini App offers a free-credits tier that abuse-resistant accounts can claim. Today: anyone can claim, scammers run thousands of throwaway sybils through your funnel. With the Trust API: gate the free-credits claim behind a trust-profile check, soft-fail to a reduced free tier for unknown accounts, full free tier for trusted accounts. Sybils get filtered without blocking legitimate new users.

2. Airdrop sybil resistance. Your TON-based project is doing an airdrop. Today: a sybil farm with 10,000 fresh wallets and 10,000 fresh Telegram accounts is the dominant claim cluster. With the Trust API: weight airdrop allocation by trust profile — high-trust accounts get full allocation, fresh accounts get a deferred allocation pending behavioral confirmation, network-co-occurrence sybils get filtered out entirely. The honest community gets proportionally more.

3. Paid community pre-screening. You run a $497/month mastermind. Today: a competitor signs up, screenshots premium content, posts it on Reddit. With the Trust API: query new signups against the ban network — if they've been banned for content-leak patterns in another paid community, the trust profile flags it. You can manually approve anyway, but you have the signal before the damage.

4. Bot anti-abuse. You run a popular Telegram bot with a free tier. Today: a competitor scripts thousands of bot accounts to drain your free tier. With the Trust API: rate-limit unknown accounts faster, fully allow trusted accounts, automatically block accounts that match the sybil-cluster pattern. Your real users get more generous limits because the abusers are filtered out.

5. Telegram-native trust badges. You run a marketplace, dating platform, or social Mini App where reputation matters. Today: you display «account age» and call it a verification signal. With the Trust API: display a community-trust score — «this user has been a trusted member of 4 Telegram communities for 18+ months». Real social proof, sourced from behavior rather than just account metadata.

What the Trust API is NOT

The distinctions here are structural, not marketing. The architecture enforces them.

Not a KYC service. The Trust API never returns real-world identity. No names, no documents, no addresses, no payment info. It returns behavioral reputation scoped to Telegram. KYC is a different category, regulated differently, and outside our scope. The data we don't store is the data we can't be subpoenaed for.

Not a data sale. Builders pay for query access to a service we operate; they don't pay to license a user database. We're never selling «here's a list of 10,000 trusted accounts you can market to». The query model is intentionally one user at a time, rate-limited, with audit logs.

Not real-world identity. User pseudonyms remain pseudonyms. We know «user ID 12345 has trust profile X»; we don't know who user 12345 is in real life. Telegram itself holds that mapping; we deliberately don't.

Not a globally-coordinated ban list. The Trust API exposes Varta's network ban signals to builders making their own trust decisions. It's not a centralized authority pushing bans across the platform. Each builder decides what to do with the signal.

Not deterministic. The API returns calibrated probabilities and structured profiles, not binary verdicts. Builders integrate them into their own decision logic.

Beta access and roadmap

We're opening a closed beta in Q3 2026, by application. The plan:

Design-partner phase (now through Q3 2026). We're looking for 3-5 design partners across distinct use cases: one Mini App with a free tier, one airdrop team, one paid community platform, one bot platform, one marketplace or social app. Design partners get free beta access, direct input on the schema and pricing tiers, and prioritized support.

Closed beta (Q3-Q4 2026). Expanded to 20-30 teams. Still free. We watch how the API performs under varied load and use cases; tune the schema based on real builder feedback.

General availability (Q1 2027). Public access, tiered pricing. Generous free tier for indie builders (we'd rather have ten Mini Apps using us free than two enterprise customers); paid tiers for teams shipping at scale.

Apply to be a design partner

Email [email protected] with three things:

1. What you're building (one paragraph).
2. What trust question you're trying to answer (one paragraph).
3. Approximate query volume you'd want in beta (a number).

I read every application and reply within a week. Design partners get a 30-minute call where we walk through the API schema and your use case in detail, then iterate on the integration with you.

This is the post I've been wanting to write for two years — back when «we're protecting communities from spam» felt like the right framing. The work hasn't changed; what changed is that the dataset got dense enough that exposing it as infrastructure starts to make sense. If you're building anything that depends on knowing whether the person on the other end of a Telegram interaction is real, real-engaged, or worth trusting — let's talk.

Varta is the Trust Layer for Telegram — AI moderation in 33 languages across 48 protected communities, with the underlying signal now being exposed as the Trust API for builders. Email [email protected] to apply for design-partner access.