The short API call hands wallet authority to a remote service
Fragment API Dev 1.3.0 sends the wallet seed in a JSON request to api-stars.duckdns.org, a service you do not operate. One Python call can buy Telegram Stars or Premium and then poll for completion, which makes the convenience easy to see. The same request may carry a 24-word mnemonic or a Base64 32-byte private key. This is a wallet-custody decision dressed as an SDK choice.
The purchase flow itself is restrained. You check whether a username can receive the product, accept the customer's payment only after a positive result, submit one order, save its purchase ID, and poll until it completes or fails. Stars can range from 50 to 1,000,000, while Premium accepts 3, 6, or 12 months. GRAM and USDT on TON are supported, though a USDT purchase still needs some GRAM for network fees.
The 25-path repository omits the purchase server
GitHub lists 21 files across 25 public paths at commit 7500f0c, including a README, an OpenAPI contract, small Python and Node examples, and a portable integration skill for Codex or Claude Code. It does not contain the hosted service implementation. You can inspect the request contract and recommended order logic, but you cannot inspect how the server stores, uses, logs, or deletes the wallet material it receives. There is also no Dockerfile or self-hosting path.
The separately published PyPI 1.3.0 source archive does include the Python client, even though that client code is absent from the GitHub checkout. It uses Python's standard library, validates usernames and purchase amounts locally, maps 400, 409, 429, and 503 responses to named errors, and creates an idempotency value when the caller omits one. That is useful client behavior. It still delegates the valuable operation, signing and submitting a purchase, to the closed server.
What happened when we ran it
Our 3-CPU, 8 GB sandbox did not run fragment-api-dev. We cloned commit 7500f0c on September 16, 2026, then measured the checkout as having no supported language ecosystem and no Dockerfile. Under our test method, that leaves no install time, build result, dependency count, test result, or vulnerability audit to report. Claiming that the package passed would turn an absent run into invented evidence.
Our read-only check of the documented host returned HTTP 200 on September 23, but a health response does not exercise wallet derivation, payment, delivery, retries, or reconciliation. We did not send a seed, create an order, or spend funds. The paid path remains outside our measurement. That boundary matches the repository tree: this is an integration kit, not the source for a runnable API service.
Version 1.3.0 requires a wallet seed for purchases
The 1.3.0 OpenAPI schema makes seed mandatory for a purchase. The client strips it, places it in the request body, and sends it over HTTPS to the hosted endpoint. A 12-word mnemonic also needs an address or account index; the service offers a resolver that receives the seed too. The repository warns against browser storage, logs, fixtures, and public issues, but transport security does not answer what happens after the server receives the credential.
The 168-byte SECURITY.md gives a Telegram contact for private reports and does not publish a data-retention policy. No server code explains whether seeds stay only in memory, reach application logs, enter a queue, or survive a failed order. For a wallet funded only with the exact amount needed for a purchase, you can bound the damage. Sending the mnemonic of a treasury or long-lived wallet would give an unaudited service far more authority than this convenience warrants.
The 1.3.0 client prevents blind order replacement
The 1.3.0 client creates an idempotency value when the caller omits one, while the integration guide tells shops to derive a stable value from their own order ID and reuse it on retries. After the API accepts a purchase, the caller saves the returned ID before polling. Only completed means success. A reconciliation_required result must stop automatic replacement, because buying again after an unclear blockchain response can charge the wallet twice.
Availability has similarly careful wording. Its result is a current check, not a price reservation or delivery promise. The docs tell callers to pause on 429, retry later on 503, and avoid charging a customer when eligibility cannot be confirmed. Those rules belong in persistent application state, not a request handler that forgets everything after a timeout. The examples are enough to design that state machine, though they cannot promise the hosted service will stay available.
Three commits are too little history for a funded wallet
GitHub shows 104 stars, 10 forks, and 0 combined open issues and pull requests. The repository was created on August 30, 2026, received its third commit on September 2, and has no GitHub release. PyPI reached 1.3.0 on September 2. This is recent activity rather than abandonment, but it provides only a short public record for software entrusted with transferable credentials and paid orders.
A 50-Star trial with an isolated wallet is the most defensible starting point. Persist every purchase state, cap its balance, and plan manual reconciliation before increasing volume. If you are unwilling to let this operator receive signing material for even that wallet, the clean client API does not compensate for the missing trust evidence.