Bot for Selling Telegram Stars with Auto-Delivery in 2026

Delivering stars by hand works until the first busy evening. Payments stack up, buyers write to ask where their stars are, and every order waits for you to copy a username and press buy.

A bot for selling Telegram Stars with auto-delivery shows the catalogue, accepts payment and credits stars to the buyer's @username without you, then messages the result. On KRAB.GG you can launch one in two ways: a ready-made franchise bot under your brand, with no developer and no checkout, or your own bot connected to the partner API.

Both paths can also sell Telegram Premium, GRAM and Steam top-ups from the same bot. This guide walks through each path, follows one order from payment to the buyer's message, shows how the money adds up and lists what usually breaks in the first week, with a task brief you can hand straight to a developer.

Bot for selling Telegram Stars: the short version

• Two paths, one platform. The franchise is a separate shop bot under your brand: the platform's checkout takes the money and the platform delivers. The API path is your own bot, site or marketplace connector: you take the money, and your server orders delivery from a USDT balance.
• The franchise needs no developer. You create a bot in @BotFather, send its token through @apistarsbot and manage prices, categories, the main-screen text and banners inside the bot.
• API pricing follows a fixed formula. Telegram products cost Fragment wholesale price + 1%; Steam is credited 1:1, so a $10 top-up debits 10 USDT. The minimum deposit is 100 USDT in the TON network.
• Delivery is fast. Stars, Premium and GRAM usually come back in the same API response with status: completed; a Steam top-up takes about 4 seconds on average.
• Most failures are predictable. Clean up usernames, always send your own orderId, fetch the price at the moment of sale and keep the live key on your server.

Terms quoted in this article are valid as of September 2026; the current ones are always in @apistarsbot and in the partner API terms.

Stars auto-delivery: 3 parts and 4 ways to run them

Every stars auto-delivery setup has three parts: a storefront, a payment step and a delivery step. The ways to sell stars differ only in who owns each part and who cleans up when something fails.

What a Telegram stars auto-delivery bot is made of

• Storefront — the bot menu or marketplace listing where the buyer picks a product and quantity and enters the recipient's @username.
• Payment — the checkout that takes the buyer's money and tells the bot the payment went through.
• Delivery — the request that credits the stars to the recipient and returns a status.

Auto-delivery means the delivery step starts by itself the moment payment is confirmed. Two more pieces decide how the shop feels to a buyer, and they are the ones most often skipped: the message with the result, and the failure branch, meaning what the bot says and does when delivery doesn't complete. Premium, GRAM and Steam top-ups run through the same chain; only the recipient field and the product type change.

Four ways Telegram bots for selling stars deliver

The table compares four common setups by the questions a seller actually faces: whose money flow it is, whose problem a failure is, and what you need on day one.

Manual delivery is fine for testing demand, but it scales only as far as your free time, and every order depends on you being online. Your own integration with the wholesale source gives full control. Open-source templates exist for this path, for example an open-source star-shop bot on GitHub built with Python, aiogram 3, PostgreSQL and Redis, but you host it, connect your own checkout and own every failure. The partner API keeps your storefront and checkout and hands off only the delivery. The franchise hands off both payment and delivery, which is why it needs no code.

A quick rule: no checkout of your own means the franchise; if you already take payments on a site, a marketplace or through a payment provider, choose the API.

Ready-made bot with no developer: the franchise

The franchise is a separate shop bot under your own brand that runs on the KRAB.GG platform. The platform's checkout accepts buyers' payments and the platform delivers the goods, so you need neither a checkout of your own nor a developer. You own the bot's name, the audience and the prices; the platform owns payment and delivery.

Who the franchise suits

• Telegram channel and community owners who already have buyers and want a shop under their own name.
• Resellers who deliver by hand today and want to stop copying usernames at night.
• Anyone testing demand before paying for development.

It suits you less if you need your own payment provider, want to build sales into an existing site or CRM, or sell on a marketplace where the marketplace takes the payment. In those cases the API is the right path.

How to create a bot for selling stars

You create the bot yourself; the platform connects it to payment and delivery.

1. Open @BotFather, send /newbot and choose the display name and the @username. This is your brand, so pick something buyers will recognise.
2. Copy the token BotFather returns. Treat it like a password: whoever holds it controls the bot.
3. Open @apistarsbot and tap «Свой бот (франчайзи)», which means Own bot (franchisee).
4. Send the token. Your application goes to review.
5. Once the bot is connected, a link arrives in your dashboard.
6. Open the admin panel inside the bot: set prices, switch product categories on or off, write the main-screen text and upload banners.
7. Share the bot with your audience and place a first order to see the flow as a buyer sees it.

Prices, income and payouts

You set your own prices and markup on top of the wholesale price. The purchase cost is visible in the bot's admin panel, and the bot won't let you sell below it, so a price can't be set under cost by mistake.

Your income per order is your price minus the purchase cost. It accumulates in the dashboard and is withdrawn to your own payment details. Income from fresh orders is temporarily frozen in case a buyer asks for a refund, so plan your cash flow with that in mind and check the current payout terms in @apistarsbot.

Buying a ready-made bot vs. a franchise

Search for a way to buy a ready-made bot for selling stars and you'll mostly find scripts and projects for sale. A script gives you code; hosting, checkout, supplier, updates and support stay with you. If an anonymous seller disappears, nobody fixes the bot when Telegram or a payment provider changes something.

The franchise is the opposite trade: nothing to host or patch, but less control over the checkout and the purchase flow than your own code gives you. If that control matters, the next section is your path.

Your own Telegram bot for selling stars via API

Your own bot on the partner API keeps the storefront and the checkout on your side, while the platform handles delivery: your server calls the API, pays for each order from your USDT balance and gets a status back. This path fits an existing shop or site, a marketplace connector, or a bot with its own payment provider and design. The endpoints, products and pricing are covered in our technical overview of the partner API; here the focus is on one order and the launch.

The path of one order

1. The buyer picks a product and quantity in your bot and enters the recipient's @username.
2. Your server calls GET /v1/check to confirm the recipient is valid before you take any money.
3. Your server calls GET /v1/price, adds your markup and shows the final price.
4. The buyer pays through your checkout. The money stays with you.
5. After your checkout confirms payment, your server calls POST /v1/orders with your own orderId, for example {"type":"stars","qty":100,"username":"@johnsmith","orderId":"order-123"}.
6. For Stars, Premium and GRAM the response usually already carries status: completed. Otherwise your server waits for the webhook or checks GET /v1/orders/{id}.
7. Your bot messages the buyer: delivered, or what happens next.

The orderId is your protection against double charges. It can be up to 128 characters from A-Za-z0-9._:-. Repeating a request with the same orderId never debits your balance twice, while the same orderId with a different product or recipient returns 409 order_id_conflict. Use the order number from your own database, not a random value generated at the moment of the request, or a retry after a crash will look like a brand-new order.

From test key to the first live order

1. Get a sk_test_ key in @apistarsbot; it is issued immediately.
2. Build the whole flow on the test key: check, price, order, webhook, buyer message. Run your first requests with dryRun: true.
3. Apply for live access. The sk_live_ key is issued after the application is approved.
4. Call GET /v1/deposit: it returns a TON-network address and a memo. Send at least 100 USDT with that memo; the deposit is usually credited within a minute. The balance is kept in USDT.
5. Put sk_live_ into your server's environment and place the first live order to yourself: your own @username, a small quantity.
6. Log the X-Request-Id header from every response next to your orderId.

If you stop using the API, the unused balance is returned on request to hello@krab.gg within up to 10 business days, as set out in the API terms.

A brief you can send your developer

If you're not a programmer, copy this list into the task for your contractor. Full request examples are in the developer documentation and the API reference.

• Generate an orderId in your own system for every purchase and reuse it on any retry.
• Normalise the username: trim spaces, strip https://t.me/ and t.me/, add @, then call GET /v1/check before accepting payment.
• Request GET /v1/price at the moment of sale; never reuse an old price.
• Call POST /v1/orders only after the checkout confirms payment.
• Accept completed from the response; otherwise wait for the webhook or poll GET /v1/orders/{id} sparingly.
• Verify the HMAC-SHA256 signature in X-Webhook-Signature on every webhook, as described in the reference. This check is mandatory.
• Treat under_review as in progress: no retry and no new orderId.
• Stay within 60 requests per minute per account; after a 429 response, wait for the Retry-After value.
• For Steam, GRAM and ads_recharge orders, read min_quantity or max_quantity from the API response and show the allowed range to the buyer.
• Keep sk_live_ in server environment variables only.
• Alert the owner when the USDT balance drops below a threshold the owner sets.

One bot for Steam top-ups and stars

A single bot can sell both, because through the partner API a Steam top-up is just another order type, credited 1:1 in the account's currency at Steam's official rate. That makes a bot for Steam top-ups a natural extension of a stars shop: same checkout, same balance, same order logic. Accounts from all CIS regions are supported.

Steam differs from Telegram products in one respect: the result usually isn't final in the first response. A Steam top-up takes about 4 seconds on average, and the outcome arrives by webhook or through GET /v1/orders/{id}. Your bot should show a processing message and write to the buyer only after the final status. The exact recipient fields are listed in the API reference; a Steam password is never part of the flow, and your bot should never ask for one.

Worked example: a $10 Steam top-up

• The buyer asks your Telegram bot for a Steam top-up of $10.
• Your server creates the order for $10.
• The platform debits 10 USDT from your balance.
• $10 lands on the buyer's Steam balance. If the account is in tenge or rubles, Steam converts the amount at its own official rate, so the buyer sees the equivalent in their wallet currency.
• The buyer paid you whatever you set: the ruble cost of 10 USDT at your rate, plus your markup and your checkout's costs.

The 1:1 part has no hidden spread, which keeps pricing simple: your cost floor is what 10 USDT costs you on the day of sale. Minimum and maximum amounts are deliberately not fixed here because they change; the API returns min_quantity or max_quantity when an order falls outside the range.

Timing matters for Steam. The Steam Autumn Sale runs October 1–8, 2026 and opens at 20:00 Moscow time (10:00 Pacific), and the Winter Sale runs from December 17, 2026 to January 4, 2027, according to our Steam sale 2026 calendar. If you're planning a launch, aim to have the bot live and tested before the Winter Sale traffic arrives.

Premium and GRAM in the same flow

Telegram Premium is sold for 3, 6 or 12 months only, so your menu needs three fixed options rather than a free quantity field. GRAM tops up the GRAM balance of a Telegram account by @username, not an external crypto wallet, which is handy for buyers who pay for Telegram Ads. Buyers who only need a one-off top-up can also buy GRAM for a Telegram account directly. Premium and GRAM orders usually complete in the same API response, just like Stars.

Stars auto-delivery on FunPay and Playerok

Stars auto-delivery on FunPay or Playerok works through a connector that watches your new orders, reads the buyer's @username and quantity, requests delivery from a supplier API and reports back in the order chat. The marketplace takes the payment, so the franchise doesn't plug in here: a marketplace setup is always an API setup.

The documentation of one FunPay automation plugin describes this cycle: automatic order monitoring, reading the username and quantity from the order, delivery, and a chat message asking the buyer to confirm the order. The same tools run checks before delivery, such as a valid username and no other unfinished order from that buyer, and cancel delivery for an order when there isn't enough stock to cover it.

Two things to keep in mind:

• Built-in marketplace auto-delivery is not the same thing. It hands out pre-loaded text or codes. Stars are credited to a specific @username, so they need delivery through an API, not a list of codes.
• Page parsing is fragile. A connector that reads order pages breaks whenever the layout changes; an official marketplace API, where one exists, is sturdier.

Marketplace rules on automation, bots and messaging buyers are set by each marketplace and change over time. Check the current FunPay and Playerok rules yourself before connecting anything; this guide doesn't cover ways around them.

How to set up stars auto-delivery on a marketplace

1. Read the marketplace's current rules for digital goods and automation.
2. Choose the connector: a ready-made tool, or a developer working from the brief above.
3. Host the connector on a server and give it the sk_live_ key there, not in a browser.
4. Build the orderId from the marketplace order number with a prefix, for example fp: plus the number (the colon is an allowed character), so a retry after a crash maps to the same order.
5. Before delivery, run GET /v1/check on the username from the order. If it fails, ask the buyer in the order chat instead of guessing.
6. After completed, message the buyer and ask them to confirm the order the way the marketplace expects.
7. On under_review or an error, tell the buyer the order is being checked and don't create a second one.

Economics: franchise margin vs. API markup

In a franchise bot your income per order is your price minus the purchase cost shown in the admin panel. With the API it's your selling price minus the cost from GET /v1/price and minus your own costs: checkout fees, currency conversion, server and development. Neither path guarantees a margin; the market sets the ceiling.

The franchise has two numbers to watch. Your price and the purchase cost both sit in the admin panel, and there's no payment-provider contract or server bill on your side. Your job is choosing a markup buyers will accept.

The API has more moving parts. The cost basis is Fragment wholesale price + 1% for Telegram products and 1:1 in USDT for Steam. Your checkout most likely takes rubles while your balance is in USDT, so the exchange rate sits between every deposit and every sale.

Here is an example with hypothetical numbers, for illustration only:

• GET /v1/price returns a cost for a pack of 1,000 stars; call it 100%.
• You add a 12% markup and charge 112%.
• Suppose your payment provider keeps 3% of the ticket: about 3.4% of cost.
• What remains before server and developer costs is about 8.6% of cost.
• If you price in rubles at an outdated rate and USDT moves 2% against you, that shrinks to about 6.6%.

The example shows why re-quoting on every sale matters more than the markup itself. Buyers compare, too: guides like DTF's 2026 rating of star-buying bots rank bots by price. A high markup rarely survives that; speed, clear support and a wider range (Stars, Premium, GRAM and Steam in one place) are easier ways to stand out.

What breaks in the first week

Most first-week failures in a stars bot come from a short list of predictable mistakes, and each has a fix you can give your developer before launch.

1. A username with a space or a t.me/ link. Buyers paste @ johnsmith, https://t.me/johnsmith or a name with a trailing space. Normalise the input and call GET /v1/check before payment, so a typo becomes a prompt to re-enter instead of a paid order with nowhere to go.
2. A retry without orderId. The connection times out, the code resends, and without an orderId the second request is a new order. With the same orderId the balance is never debited twice. A 409 order_id_conflict means your code reused an orderId for a different product or recipient: fix the code rather than changing the id to push the order through.
3. Selling at yesterday's price. A price cached in the morning is wrong by evening if the rate moved. Request GET /v1/price at the moment of sale and give each quote a short validity window in your bot.
4. An empty balance on a peak evening. Demand spikes on sale evenings; the Steam Autumn Sale opens at 20:00 Moscow time on October 1, 2026. A deposit is usually credited within a minute, but only after someone sends it. Set a balance alert and switch products off in your bot when the balance can't cover the next order.
5. A webhook without signature verification. Anyone who finds your webhook URL can send a fake completed. Verifying the HMAC-SHA256 signature in X-Webhook-Signature on every call is mandatory; the method is described in the API reference.
6. A key in client-side code. A sk_live_ key in a Mini App, a web page or a public repository is a key anyone can use. All API calls must go from your server.
7. A retry on under_review. The code sees a non-final status, decides the order failed and creates a new one.
8. Hitting the rate limit. Polling GET /v1/orders/{id} every second for every order burns through 60 requests per minute fast. Rely on webhooks, poll sparingly and respect Retry-After after a 429.

When you need help, send support (@heIIo_stars) the orderId and the X-Request-Id from the response. That pair points to the exact request, and support replies in about 1–3 minutes on average.

Which path to choose and what to do today

The choice comes down to one question: do you already have a way to take payments?

• No checkout and no developer — choose the franchise. Today: create a bot in @BotFather and send its token through @apistarsbot.
• A site, a marketplace listing or your own payment provider — choose the API. Today: get a sk_test_ key in @apistarsbot, send your developer the brief above and plan the 100 USDT deposit before launch.
• Delivering by hand right now — either path works; decide whether you'd rather own the checkout or hand it off.

KRAB.GG has been on the market since 2024, holds a 5/5 rating and runs at 99.98% uptime. Prices and exchange rates move, so the current cost is always in the API or the bot's admin panel; follow the rules of Telegram, Steam and any marketplace you sell on, and treat the numbers here as information, not financial advice. Open @apistarsbot, pick the path that matches your checkout, and get your first order through before the Winter Sale.