Fragment API for Telegram Stars, Premium, GRAM and Steam in 2026

Building a Telegram bot with a Stars storefront is easy. The trouble starts later: an order comes in at 3 a.m., and it has to be delivered with nobody at the screen, no typo in the username and no double charge. That's usually when developers start searching for a Fragment API.

Short answer: there is no official public Fragment API for buying Telegram Stars and Premium. Fragment publishes no documentation for such an API, and everything on GitHub and PyPI under that name is an unofficial wrapper around the website. You can buy Stars, Premium and GRAM programmatically in three ways: an open-source library, your own script or a supplier API.

Below we compare the three options by what matters most for a business: what you have to store on your side and who deals with failures. Then we walk through the KRAB.GG partner API in detail: products, pricing, reliability, setup and integration mistakes. One thing up front: our API is not a Fragment API. We don't represent Fragment or Telegram. For us, Fragment is Telegram's marketplace and the basis of the price.

Buying Stars programmatically: the short version

• Fragment has no official public API. The libraries on GitHub and PyPI describe themselves as unofficial.
• A library needs your secrets: Fragment account cookies or a wallet seed phrase, plus GRAM in that wallet. Failures are yours to debug too.
• With a supplier API, you store only a key. Orders are paid from a single USDT balance. Stars, Premium and GRAM cost the Fragment wholesale price plus 1%; Steam is credited 1:1 with no fee.
• You can check reliability before your first payment: a no-charge sandbox, idempotency by orderId, signed webhooks.
• The terms in this article are valid as of September 2026. The current version is always in the API terms of service.

What people call a Fragment API, and is there an official one

"Fragment API" is an umbrella name for unofficial libraries and scripts that replay user actions on fragment.com: buying Stars and Premium, topping up ads in GRAM. Fragment publishes no public API documentation for these purchases, and library authors say so openly.

• The author of the Python library Ton-Fragment on GitHub explains in the README that he tried to pull data from Fragment.com and found no official API.
• The fragment-api-py client describes itself as a "non-official python client for Fragment API".
• The fragment-stars topic on GitHub lists several projects, each with its own account and wallet requirements.

Telegram describes the official ways to get Stars in its bot documentation on Stars payments at core.telegram.org. There, users buy Stars through Apple and Google in-app purchases or via @PremiumBot. There's no separate Fragment API for resellers.

The search "fragment telegram api" sometimes gets mixed up with the Bot API. The Bot API does have a giftPremiumSubscription method: a bot gifts Premium to a user and pays with its own Stars. You can't buy the Stars themselves at the Fragment price with it, so it doesn't solve wholesale delivery.

The practical takeaway: any "Fragment API" runs on top of the website interface, not a public contract. The marketplace has no obligations to integrators. If a page, the login flow or a request format changes, the wrapper stops working until its author updates it.

Three ways to buy Telegram Stars via API

You can buy Telegram Stars programmatically through an open-source library, your own script or a supplier API. Anyone searching for a "telegram stars api" or an "API to buy Telegram Stars" is choosing between exactly these. The difference isn't how fast you get the first run working — it's what sits on your server and who is responsible for a stuck order.

For a digital goods shop, the last row often decides it. Fragment doesn't sell Steam, so Fragment wrappers can't cover that product.

What open-source libraries require

Search results for "fragment api stars" are almost entirely GitHub and PyPI repositories. The fragment-api-py README describes two modes:

• with a verified Fragment account: the library needs the account cookies and a wallet, and suggests storing the cookies in files or Redis;
• without verification, via a third-party service API: you need that service's token, a 12-, 18- or 24-word wallet seed phrase and an API key from a blockchain provider.

Either way, your server holds secrets with access to money, and orders are paid in GRAM from your wallet. Topping up the wallet, watching the balance and reconciling transactions are also on you.

There's a separate class of packages that look like a library but are really a thin SDK for someone else's server. You send it your wallet mnemonic, and the server buys on your behalf. One README even suggests Base64-encoding the whole phrase before sending it. Formally it's a PyPI package; in practice it's a middleman with full access to your wallet.

One more 2026 detail: in June Toncoin was renamed GRAM, while the network stayed the same — The Open Network. Some wrappers have already switched to the new name: the fragment-api-py README lists "GRAM Ads top-up". Older versions and examples still use TON and ton in parameters. Check which version you're installing, and budget time to update the dependency after each release.

Why your own script breaks first

Your own script means manually emulating Fragment website requests without anyone's library. You get full control, and full maintenance with it. If the login form or response structure changes, delivery stops, and you hear about it from a customer. You'll have to write the queue, retries and transaction reconciliation yourself. The same goes for cases where Fragment asks you to verify the account manually.

This route makes sense for a learning project or one-off purchases for your own account. For a shop where a Friday-night order has to go out without an on-call developer, it's the riskiest of the three.

How the KRAB.GG partner API works

The KRAB.GG partner API is a REST API with the base URL https://api.krab.gg/v1. A bot, shop or CRM creates an order with a single request, and the product goes to the specified recipient. The key goes in the Authorization: Bearer sk_live_… header. No password, login code or access to the recipient's account is needed for any product. Stars and Premium arrive through Telegram's built-in payment mechanism — the same official flow as an in-app purchase.

That's what topping up Telegram Stars via API looks like in practice, and the same integration covers six more types of digital products.

Available products and recipients

If you're looking for an API to sell Telegram Premium, note the qty field: for Premium it means the term, not a quantity.

• stars — Telegram Stars, from 50 to 10,000,000 per order. Recipient: @username.
• premium — Telegram Premium for 3, 6 or 12 months; qty is the term in months. There's no 1-month plan. Recipient: @username.
• gram — GRAM credited to a Telegram account balance. Recipient: @username; an external wallet address won't work.
• steam — Steam balance top-up in dollars. Recipient: the Steam account login without @.
• stars_giveaway — a Stars giveaway in a channel. qty is the whole star pool from fixed Fragment packages (500 to 1,000,000), winners is at most qty ÷ 100. Recipient: the channel's @handle.
• premium_giveaway — a Premium giveaway in a channel. qty is the term of each subscription (3, 6 or 12 months), winners is the number of subscriptions, up to 24,000. Recipient: the channel's @handle.
• ads_recharge — a Telegram Ads account top-up; qty is whole GRAM. Recipient: the token from the "Add Funds on Fragment" link like fragment.com/ads/pay?account=…; you can send the whole link.

Giveaways have a nuance worth explaining to customers in advance. After payment, the giveaway appears to the channel admins in the Boosts section (Statistics → Boosts). The admin sets the end date and entry conditions, and Telegram picks and rewards the winners. A personal account or a bot can't be the recipient.

Telegram gifts are not delivered via the API: POST /v1/orders rejects such an order with an error; gifts are available only on the site and in the bot. Amount limits for steam, gram and ads_recharge change, so don't hardcode them. If you go out of bounds, the API returns min_quantity or max_quantity.

Endpoints and order body

• POST /v1/orders — create an order and deliver it immediately;
• GET /v1/orders/{id} — order status;
• GET /v1/price — price quote without charging;
• GET /v1/check — check whether the recipient accepts the product;
• GET /v1/balance — current balance;
• GET /v1/deposit — top-up details;
• GET and POST /v1/webhook — webhook settings.

The order body has four fields: type, qty, username and orderId, plus an optional dryRun. Giveaways require a fifth field, winners; it's rejected for all other products. A minimal order is POST /v1/orders with the body {"type":"stars","qty":100,"username":"@johnsmith","orderId":"order-123"}.

Full request and response examples are in the partner API documentation. Parameters and response codes for each method are in the endpoint reference.

Steam top-up via API: 1:1 in dollars

The Steam top-up API credits exactly the amount you ordered: order $10 and $10 lands on the Steam balance, with 10 USDT charged to the partner balance. There's no fee on the steam type and no hidden markup. Funds are credited in the account's currency at Steam's official rate.

• Recipient — the Steam account login without @. No password or login code needed.
• Regions — accounts from all CIS regions work.
• Speed — delivery is asynchronous; an order completes in about 4 seconds on average. The outcome comes via webhook or GET /v1/orders/{id}, so processing in the POST response is a normal state, not an error.
• Amount limits are returned by the API as min_quantity and max_quantity. Don't hardcode them.

For a digital goods shop, this means Steam and Telegram products share one balance and one status logic. No second supplier, second balance or second reconciliation scheme. The cost of a top-up equals its amount, so pricing Steam is simpler than any other product.

Run the steam type through the sandbox before a big sale, not during it. Dates for the next one are in our article on the Steam Autumn Sale 2026.

Fragment API pricing: Fragment wholesale + 1%

In the partner API, Stars, Premium and GRAM cost the Fragment wholesale price plus a 1% fee. Steam top-ups carry no fee. Giveaway and Telegram Ads top-up prices come only from GET /v1/price. If you need a wholesale Telegram Stars supplier with an API, the formula is: the marketplace price as the base, the percentage on top, then your markup.

• One USDT balance for all products; no separate GRAM wallet needed.
• The exact order price comes from GET /v1/price, quoted without charging. The Fragment wholesale price moves, so figures from articles or a day-old cache won't do for a storefront.
• You set the markup, with no upper cap.
• Top-up — USDT on the TON network to the address with the mandatory memo from GET /v1/deposit. Minimum 100 USDT, usually credited within a minute. Without the memo, the funds won't be credited.
• Refund of the remaining balance: unused balance is returned on request to hello@krab.gg within 10 business days (offer, version 2.2 of 28.09.2026).
• Custom volume terms can be discussed with support at @heIIo_stars.

Example calculation

The figures below are illustrative and only show the formula. Say the Fragment wholesale price for a Stars package is 20.00 USDT. With the 1% fee, the order costs you 20.20 USDT. If the customer pays you the equivalent of 23 USDT, the gross margin is 2.80 USDT. From that you still subtract payment processing, taxes and support. Steam is simpler: a $10 top-up costs you 10 USDT, and anything above is your markup.

In a real integration, don't calculate the final order price yourself — take it from GET /v1/price. These requests use the same 60-requests-per-minute limit as orders. If your storefront shows a price to every visitor, cache the response briefly and fetch a fresh price at checkout. That keeps you clear of 429s during peak hours.

Two caveats. The partner API is not the affiliate program. In the affiliate program you earn a share of orders from customers you refer; here you buy at wholesale and resell with your own markup. And this isn't financial advice: results depend on your prices, demand and costs; there's no guaranteed margin.

Reliability: no double deliveries, no lost orders

The partner API's reliability rests on five mechanisms: idempotency by orderId, recipient checks via GET /v1/check, explicit statuses with a settlement field, signed webhooks and the X-Request-Id header for troubleshooting.

Idempotency by orderId

orderId is your order identifier, up to 128 characters from the set A-Za-z0-9._:-. Repeating a request with the same orderId returns the existing order and never charges twice. A timeout, dropped connection or crashed worker is solved by simply resending the same request.

If you send the same orderId with a different type, qty or username, the API returns 409 order_id_conflict. This guards against a bug where one identifier accidentally gets attached to another product or recipient. The easiest approach is to build orderId from the order number in your database, e.g. shop:48213, rather than generating a random one on every attempt.

Fragment libraries offer no such protection. The README of one popular wrapper says plainly that you must not blindly retry a request if the transaction may already have been signed or sent.

Recipient check and username normalization

Before charging the customer, call GET /v1/check: it tells you whether the recipient will accept the product. Before that, normalize the customer's input to catch format errors before the request:

1. Trim spaces and invisible characters at both ends.
2. If the customer sent a link like t.me/name or https://t.me/name, keep only the name.
3. Strip all leading @ and add exactly one.
4. For Steam, do the opposite: login without @. It has to be the login, not the profile name.
5. For ads_recharge, no username is needed: accept the token from the "Add Funds on Fragment" link or the whole link.
6. Only then call GET /v1/check and show the customer the result before payment.

Normalization and the check catch different errors. Normalization filters out bad formats; the API check shows whether the recipient exists and can accept the product.

Statuses and settlement

An order has five statuses: completed, processing, failed, refunded and cancelled. Stars, Premium and GRAM are usually delivered synchronously within seconds and come back with status: completed in the same response. Steam is delivered asynchronously. Giveaways and ads_recharge have no fixed delivery time; the status or webhook decides the outcome.

On failed, the response includes reason and retryable. If retryable: true, the money is already back on the balance and retrying with a new orderId makes sense. If delivery isn't confirmed, the order gets settlement: fail_hold. With under_review, funds are held pending a manual check. In both cases, don't create a duplicate.

Webhooks, rate limits and X-Request-Id

• Webhooks order.completed, order.failed and order.updated carry settlement and an increasing sequence. Apply an event only if its sequence is greater than the one you've stored. That way a late order.updated won't overwrite a final status.
• The HMAC-SHA256 signature arrives in the X-Webhook-Signature header, and verifying it is mandatory. Without verification, anyone who learns the URL can send a fake order.completed. The verification steps are in the documentation.
• X-Request-Id from the response should be logged next to orderId: support uses it to find the exact request.
• The rate limit is 60 requests per minute for the whole account, shared by live and test keys. Exceeding it returns 429 with a Retry-After header: wait the specified time instead of retrying immediately.
• The key is shown once, only its hash is stored, and revocation is instant. If a key leaks, revoke it and issue a new one.

How to connect the partner API

Setup takes five steps. The first two need neither money nor an approved application.

1. Issue a test key. sk_test_ is issued instantly in the @apistarsbot cabinet. The key is shown once, so store it in your server secrets, not in code.
2. Run the flow in the sandbox: GET /v1/price → GET /v1/check → POST /v1/orders → GET /v1/orders/{id} → receive a webhook and verify its signature. Separately test a retry with the same orderId and the 409 response when qty is changed. Test requests use the same 60-per-minute limit as live ones, so don't run load tests during sales hours.
3. Top up the balance. Take the address and memo from GET /v1/deposit and send USDT on the TON network, minimum 100 USDT. Confirm the credit via GET /v1/balance.
4. Apply for a live key. sk_live_ is issued after your application is approved. Custom volume terms can be discussed with support.
5. Place the first order for yourself. Order the minimum Stars package (50) to your own @username. Check the charge in GET /v1/balance, the status in the response and the incoming webhook. Only then open delivery to customers.

Integration mistakes and how to avoid them

Most integration problems aren't API failures but mistakes in the request body and in response handling. Here are the common ones and their consequences.

Request body mistakes

• A new orderId for every attempt. A retry after a timeout becomes a second order and a second charge. Fix: take orderId from the order number in your database.
• Wrong field names and an extra path prefix. The API accepts only type, qty, username, orderId, dryRun and, for giveaways, winners, and the path starts with /v1. An order with other fields won't go through.
• Treating Premium qty as a quantity. qty: 3 means three months, not three subscriptions. In a Premium giveaway, the number of subscriptions is set by winners.
• winners in the wrong place. It's required for giveaways, and for a Stars giveaway it can't exceed qty ÷ 100. For all other products it's rejected.
• A giveaway to a personal account or a bot. Only a channel's @handle can be the recipient.
• A username instead of a token for Telegram Ads. The ad account is topped up by the token from the "Add Funds on Fragment" link, not by @username or a numeric id.
• A Steam login with @, or a profile name instead of the login. The money goes to the wrong place, or the order fails the check.
• Gifts via the API. POST /v1/orders rejects such an order with an error.

Response handling mistakes

• Hardcoded prices and limits. Take prices from GET /v1/price and limits from min_quantity and max_quantity.
• Expecting a synchronous response for Steam, giveaways and Ads. processing isn't an error. The outcome arrives via webhook or GET /v1/orders/{id}.
• A duplicate on fail_hold or under_review. A new order at this point risks double delivery. Wait for the outcome and retry only on retryable: true.
• Unverified webhook signatures. A fake event will mark an order as completed even though the customer received nothing.
• Ignoring sequence. An old event will overwrite a fresh status.
• Retrying right after a 429. The counter is shared across the account, so a burst of retries keeps live orders throttled too. Wait as long as Retry-After says.
• A key in the frontend or the repository. Revoke it in the bot cabinet and issue a new one; revocation is instant.

If you stay on a library

Some mistakes are specific to Fragment wrappers, and their authors describe them in the READMEs. These include a username without @ and retrying after a transaction with an unknown status. Add to that seed phrases or cookies in the frontend and the hourly limits of the no-verification mode. Delivery also stops when Fragment asks for additional account verification. Plan manual review and on-call coverage for these cases in advance.

Library or Telegram Stars supplier: which to choose

A library is enough if you have your own verified Fragment account, a wallet with GRAM and a small order volume. You only get two products — Stars and Premium — and you're ready to handle failures and dependency updates yourself. For a small project starting out, that's a fair option.

A supplier API makes sense when:

• your bot or shop sells Stars, Premium and GRAM, and you don't want a seed phrase and cookies on your server;
• your digital goods shop needs Steam in the same integration and on the same balance;
• an agency or admin sells channel giveaways and Telegram Ads top-ups to clients;
• a CRM or service needs statuses, signed webhooks and one USDT balance instead of a GRAM wallet;
• orders come in at night and on weekends, and manual delivery leads to delays and username typos.

If there's no developer on the team, @apistarsbot offers a ready-made franchise bot: the platform accepts payments and delivers the products, and you set the prices. We covered the seller side — your own bot, auto-delivery, working with marketplaces — in a separate blog article about bots for selling Stars.

If you do have a developer, start with a test key. Issue sk_test_, run the documented flow in the sandbox and decide based on test results, not promises. The KRAB.GG partner API sandbox is available before your first top-up, so you can verify the contract before putting in any money.