Connect an SMM panel to TGRU: Perfectpanel-compatible API v2

TGRU Team September 29, 2026 7 min read

Updated September 2026

Before you start

TGRU's reseller API speaks the same Perfectpanel-standard shape most SMM panel scripts already expect from a provider: one endpoint, form-encoded POST requests, JSON back. If your panel software has an "Add Provider" or "Add API" form asking for a URL and a key, this is typically a same-day integration — no custom parsing beyond what the panel already does for every other provider. Building your own tooling instead of using an off-the-shelf panel script works the same way: everything below is plain HTTP, so any language that can send a form-encoded POST and parse JSON can drive it.

Get your API key

Sign in to your TGRU account and open the API docs — your key lives there. Rotate it if it ever leaks; rotating invalidates the previous key immediately, so update every panel that references it in the same pass.

Endpoint and request shape

Method: POST
URL: https://tgru.dev/api/v2
Body: form-encoded (application/x-www-form-urlencoded), not a JSON payload — every request sends key and action as form fields, plus whatever the action needs.
Response: JSON, always.

If your panel script has a generic Perfectpanel-compatible provider template, point it at that URL with your key and it should resolve every action below without extra mapping. Full parameter tables live on the API docs page.

The actions

All requests go to the same endpoint; the action parameter selects what happens. The full parameter list for each is on the TGRU API reference.

Action	What it does	Key parameters
`services`	Returns the full catalogue with rate, min, max, refill and cancel flags	`key`
`add`	Places an order (default, drip-feed, custom comments, polls and other types)	`service`, `link`, `quantity`, optional `runs` + `interval`
`status`	Status of one order	`order`
`status` (multiple)	Status of up to many orders in one call	`orders` (comma-separated)
`refill`	Requests a refill on a covered order inside its window	`order`
`refill_status`	Checks a refill request	`refill`
`cancel`	Requests cancellation of pending/in-progress orders	`orders`
`balance`	Returns your account balance and currency	`key`

Service list

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=services

[
  {
    "service":  1,
    "name":     "Followers",
    "type":     "Default",
    "category": "First Category",
    "rate":     "0.90",
    "min":      "50",
    "max":      "10000",
    "refill":   true,
    "cancel":   true
  }
]

Pull this on a schedule — nightly is typical — rather than once at setup. TGRU runs close to 955 active services and rates move.

Add order

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=add
service=601
link=https://t.me/yourchannel/482
quantity=500
runs=5
interval=60

{ "order": 23501 }

Service 601 here is Comments – Non Drop, Mix Country; swap in whichever service ID a buyer picked from the synced list. runs and interval are optional and turn a single order into a drip-feed — runs timed batches, interval minutes apart. TGRU charges the full order up front; runs that haven't fired yet refund to balance if the order is cancelled.

Custom comments

Swap quantity for a comments field, sent as one string with lines separated by \r\n or \n — shown one per line below for clarity:

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=add
service=601
link=https://t.me/yourchannel/482
comments=Great post!
Love this update
Saving this one

Poll votes

Poll-vote services take an answer_number alongside the usual quantity, so the order lands against one specific answer in an existing poll:

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=add
service=632
link=https://t.me/yourchannel/900
quantity=200
answer_number=2

Order status and multi-status

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=status
order=23501

{
  "charge":      "0.27819",
  "start_count": "3572",
  "status":      "Partial",
  "remains":     "157",
  "currency":    "USD"
}

For more than one order, send orders (comma-separated) instead of order, and check each result independently — one bad ID doesn't fail the rest:

{
  "1":  { "charge": "0.27819", "start_count": "3572", "status": "Partial", "remains": "157", "currency": "USD" },
  "10": { "error": "Incorrect order ID" }
}

Prefer multi-status over polling single orders in a loop — TGRU's own FAQ is explicit that burst calls risk a rate flag, where a batched pull covering the same orders doesn't.

Refill and refill status

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=refill
order=23501

{ "refill": "1" }

Then check it:

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=refill_status
refill=1

{ "status": "Completed" }

Both actions also take a multiple form — orders= for refill, refills= for status — returning an array so you can batch a whole page of order rows in one call instead of one request per row.

Cancel and balance

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=cancel
orders=23501,23502

[
  { "order": 23501, "cancel": 1 },
  { "order": 23502, "cancel": { "error": "Incorrect order ID" } }
]

POST https://tgru.dev/api/v2
key=YOUR_API_KEY
action=balance

{ "balance": "100.84292", "currency": "USD" }

Mass orders on TGRU's own dashboard

Outside the API, TGRU's own New Order screen has a Mass tab for manual bulk entry — one line per job, formatted service_id | link | quantity. That's a dashboard convenience, not a separate API action: a panel integration reaches the same result by looping action=add calls, one per row, against whichever service IDs the buyer selected. If you're building a bulk-order feature into your own panel front end for buyers, the same pattern applies on your side — parse the pasted lines, validate each service_id against your synced list, then fire one add call per row and store the returned order ID against that row so status checks can be batched later with multi-status.

Testing before you go live

Before pointing real buyer traffic at the integration, place one order against a low-minimum service using your own key, and walk it through the full loop: confirm the order ID comes back, poll status until it settles, and if the service supports refill, trigger refill and follow it through refill_status to Completed. That single pass confirms your panel's field mapping — service, link, quantity — lines up with what TGRU expects, and that your status-polling logic correctly reads Partial, Completed and error shapes before a paying customer sees any of it.

Syncing the service list and setting markup

Most panel scripts store the rate field from action=services as your cost basis, then apply a markup percentage or a flat multiplier before showing a price to your buyers. Re-pull the list on a schedule so a rate change on TGRU's side doesn't undercut, or silently overcharge against, your published price. Keep the service ID as your join key — names occasionally get cosmetic edits, IDs don't. Cross-check a sample against the live catalog, from a comments line like service 601 through to a views line like Post Views – Mix Country, to confirm your sync mapped correctly.

Handling Partial and refill statuses

A status of Partial means TGRU delivered some but not all of the order — the undelivered cost returns to your TGRU balance automatically, no refill call needed for that part. What your panel does with that is your own logic: pass the partial delivery through to the buyer's order row, or apply your own margin rule to it. Refill is a separate action, only useful inside the refill window printed on the service card, and only restores what was actually delivered, not the original order size.

One order per link

Enforce this at the panel level if you can: don't let two orders queue against the same link at the same time. Parallel jobs on one link scramble the refill baseline for both orders, which surfaces later as a support ticket neither order can cleanly resolve.

FAQ

Is the request body JSON or form-encoded? Form-encoded, the same as an HTML form POST. The response back is JSON in every case.

Does the API support bulk order creation in one call? No — each add call places one order. Multi-order convenience lives in status, refill and refill_status, all of which accept comma-separated IDs and return an array.

Is there a rate limit? No published hard number, but burst scraping or a shared key risks revocation. Batch through multi-status and multi-refill rather than looping single-order calls.

Can I set my own markup on TGRU's rates? Yes — resell under your own brand and pricing. You own support for your buyers and carry compliance with TGRU's terms through to them.

Do custom comment orders still need a quantity field? No — for the Custom Comments variant, the delivered quantity is implied by the number of lines in comments. Send service, link and comments only; TGRU counts the lines.

Connect it

Everything above runs off one API key and one endpoint, https://tgru.dev/api/v2. Create a reseller account, grab your key from the API docs, and point your panel's provider form at it; check the FAQ first if you're setting up 2FA or your first deposit alongside the integration.