What to Ask Before You Wire Money Into a Telegram Stars API

You have decided to sell Telegram Stars or Premium inside your product. You find a service with an API, the docs look reasonable, and you get as far as the first order call before the flow stops and asks you to fund a balance.

Not to pay for the order. To deposit money, in advance, into an account they control, so that later orders can draw it down.

That is the moment worth slowing down for, and almost nobody does. This is a guide to the eight questions we think you should ask any Stars or Premium API before you send it a single coin — written by people who build one, which you should factor in accordingly. We are not naming competitors. You can run this checklist yourself in an afternoon, and it works on us too.

Why this market looks the way it does

A short piece of context makes the rest make sense.

There is no official public developer API for buying Telegram Stars or Premium in bulk. Fragment, the platform where the bulk route lives, does not publish one. Everything you find with "Fragment API" in the name is a third party that reverse-engineered the web interface and wrapped it. That is not a smear — the maintainers say so themselves; one popular open-source project opens its README explaining the author went looking for an official API, did not find one, and wrote his own.

In November 2024 Fragment added mandatory identity verification to that purchase route, and a whole layer of intermediaries grew up between it and everyone else.

So the market you are shopping in is a middleman market by construction. That is fine — middlemen solve real problems. But it explains why so many of these services default to the same shape: an account, a dashboard, and a balance they hold. That shape is inherited from the SMM-panel world, not designed for developers.

The question everyone asks first — and why it is the wrong one

Almost every buyer opens with "do I need KYC?"

Stop using that as a selection criterion. Not because it does not matter, but because it no longer separates anyone. Every single provider we looked at advertises no KYC, most as a footer badge or a page title. It is the standard uniform in this market.

Which means when you pick a service because it does not ask for your passport, you have not actually chosen anything. You have selected on a feature that is universal, and skipped past the questions that genuinely differ. Those are next.

1. Who is holding your money?

This is the whole ballgame, and it is the question the pricing page will not answer.

At the top level there are two architectures. Either the service takes custody of your funds — you send crypto to an address they control, they credit an internal number, and orders draw that number down — or it does not, and each order is paid individually to a destination tied to that order. (The second one hides a fork, which is question 2.)

The first model is the norm by a wide margin. Of the seven services we examined closely, five take custody: your money sits with them, denominated in their internal ledger, for as long as you keep a balance. The other two do not hold a balance — and the next question explains why that is not automatically the good news it sounds like.

Ask it in plain words: if this company disappeared tomorrow, what would I lose? Under custody, the answer is your entire balance. Under per-order payment, the answer is at most one order.

2. If you do not prepay, what are they taking instead?

Related but distinct, and this is where the market splits into three — which surprised us when we mapped it.

A prepaid model means working capital leaves your business before you have made a sale. If you keep a $2,000 float so you never run dry on a weekend, that $2,000 is not in your business — it is an interest-free loan to a supplier, and you carry the counterparty risk on it. Most of the market works this way, and several are prepaid by architecture rather than policy: the generic SMM-panel API many of them expose has balance and add as core actions and no concept of paying for one order at a time. The shape of the API tells you the shape of the business.

But a minority genuinely do not hold a balance — and it is worth knowing what they ask for instead, because at least one of them wants your wallet's private key, so it can sign payments on your behalf.

Read that again before deciding it sounds convenient. A custodial balance caps your worst case at the balance. A private key caps your worst case at everything in that wallet, forever, including funds you add later and funds that have nothing to do with this integration. It is not a lighter version of custody. It is a heavier one wearing a non-custodial label.

So the question has three possible answers, and only one of them is good:

1. They hold a balance — your loss ceiling is the float you keep with them.
2. They hold your key — your loss ceiling is the wallet.
3. You pay per order, from a wallet only you control — your loss ceiling is one order.

If a provider tells you it is non-custodial, ask the follow-up: non-custodial of what? Never hand a seed phrase, mnemonic or private key to a supplier. There is no integration convenient enough to justify it.

3. Can you get the unused balance back?

If the answer to (1) is custody, this is the follow-up, and it is where reading the terms of service stops being a formality.

You are looking for a withdrawal clause, a refund policy for unused balance, or a dormancy provision. What we generally found instead is language describing the balance as credit toward future purchases — with no documented way to convert it back into money, and no stated limit on how long it can be held.

That is not necessarily bad faith. It is more often a startup that never wrote the clause. But the practical consequence is identical: treat any deposit as spent at the moment you send it, and size it accordingly. Deposit what you expect to consume this month, not what is convenient.

In one case we could not find terms of service at all — no agreement of any kind governing a custodial balance. Whatever else that is, it is not a contract you can rely on.

4. Can you onboard and operate without a web console?

A developer-facing product should be operable from code. In practice, most of these services require a web dashboard to bootstrap: create an account, log in, click into settings, generate a key. Several keep permanent functions dashboard-only — webhook configuration, price lists, plan changes — so the API alone can never run the business.

This matters more than it sounds. A console in the critical path means onboarding cannot be scripted, credentials cannot be rotated programmatically, and there is a browser session somewhere that is now a production dependency.

Ask: can I go from zero to a working key without opening a browser? For most of this market the honest answer is no.

5. Are the webhooks signed, and do they retry?

Now the engineering questions, which are quicker to check and just as revealing.

Of the seven services we examined in depth, five have no usable signed webhook. Four have no webhooks at all — you poll, forever, and hope your interval is tight enough. One sends them unsigned, which means the endpoint that credits your users' balances can be called by anyone who guesses the URL. Several of the rest have no documented retry policy, so a five-second blip on your side silently loses the event.

What to look for: an HMAC signature over the raw request body, a documented retry schedule with backoff, and some story for what happens after the retries are exhausted. Then verify it in constant time, hash the raw body rather than a re-serialised object, and handle a rotation window where old and new signatures are both valid.

6. What happens when your call gets retried?

Your queue redelivers. Your worker restarts mid-flight. A timeout fires on a request that actually succeeded.

If the API has no idempotency mechanism, every one of those is a duplicate order — you find out from your ledger, weeks later. Ask whether order creation accepts an idempotency key, whether replaying it returns the original order rather than creating a second one, and whether the same key with a different body is rejected rather than quietly accepted.

If the answer is "just don't retry", that is not an answer. Distributed systems retry.

7. Who is the counterparty?

The least technical question and often the most informative.

Look up the domain's registration date. Look for a named legal entity and a jurisdiction. Look for an independent footprint — reviews, a track record, anything not written by the operator.

When we ran this, several services holding customer prepaid balances turned out to be running on domains registered six to eight weeks earlier, with no company name published anywhere and no way to reach a human. That is not proof of anything. But you are being asked to hand working capital to an anonymous party under no written agreement, and that is a business decision, not a technical one — it belongs in front of whoever signs off on risk, not buried in an integration ticket.

8. Is the wholesale price actually wholesale?

Finally, check the arithmetic, because "reseller pricing" is sometimes a page rather than a discount.

We compared one provider's reseller sheet against its own public buy page, line by line. They matched exactly. The API was a convenience layer, not a wholesale channel — which may still be worth paying for, but is a very different product from the one being advertised.

Take the actual per-unit number from the reseller documentation and compare it against what the same service charges a walk-in customer. If they are the same, you now know what you are buying.

What we cannot do either

A checklist written by a vendor is worth very little if it only has questions the vendor passes. So, plainly, here are ours.

• There is no test mode. Pricing, catalogue and recipient-eligibility calls are reads and move no money, so you can wire the whole flow before committing. But there is no simulated order — the first real order is a real order.
• We publish no delivery-time commitment. We measure it internally and we are not going to quote a number we have not committed to publicly.
• Delivery is by @username only. A recipient without a handle cannot be delivered to. That is a platform property, not something any provider can engineer around, and it will shape your claim flow.
• Reversals are not free. When a payment lands outside the tolerance band it is returned on-chain minus the network fee, and amounts below a dust floor are not returned at all.
• We sell Stars and Premium. Not collectible gifts, not ads. If your product depends on NFT gifts, this covers part of your stack.

How we answer our own checklist

For completeness, since we just handed you a tool to use on us:

Nobody holds your money — each order is paid individually, and there is no balance with us to lose. There is no prepaid deposit, so nothing to withdraw and no unused-balance clause to read. We never ask for a seed phrase, mnemonic or private key; you pay each order from a wallet only you control, and if you use our optional wallet package the key is generated locally and never leaves your process. There is no dashboard at all: you get a key by tapping a button in our Telegram bot, and rotation, revocation and usage all happen with bot commands. Webhooks are HMAC-signed over the raw body, retried with backoff and dead-lettered after that, with a rotation window where both signatures are accepted. Order creation requires an idempotency key.

And on the question everyone opens with — no, we do not ask for KYC either. As established, so does everyone else. It should not be why you pick us.

If you want to see how we answer them in code rather than prose, the developer overview is the short version and the API reference is the long one. For a hands-on integration walkthrough — SDK setup, your first backend route, webhook verification — see our Fragment API SDK guide. And if you are earlier than that and still working out what Stars are for, start with what Telegram Stars are.