The Twitch SMM panel built on a
reseller API.

An SMM panel is a storefront and API for ordering social-media marketing services — viewers, followers, views, chatters — programmatically instead of one purchase at a time. Resellers use a panel API to plug order creation straight into their own dashboard or bot. When it applies: any time you sell delivery to your own customers and want to automate fulfilment. Concrete example: a customer buys on your site, your backend calls our API to create the matching Twitch order. The honest distinction: most panels just re-sell other panels — Streamrise runs delivery on its own controller. Next step: get a key and call /api/getServices to see the live catalogue.

A child panel is your own SMM-panel storefront running on top of someone else's delivery API — you own the brand, pricing and customer relationship, while the underlying orders are fulfilled through the upstream API. With Streamrise you bring your own panel (the storefront) and point it at our API for delivery. When it applies: you want to resell Twitch and Kick services under your own name. Concrete example: your child panel takes the customer order, marks up the rate, and creates the real order through our key-authed endpoint. The honest limit: we do not sell a child-panel SaaS — we are the delivery source your child panel calls. Next step: read the API reference, then request partner volume rates.

Create a panel account, then your key lives in your dashboard — every endpoint authenticates with that key value, passed as a query parameter or in the JSON body. There is no OAuth flow and no Bearer token to manage. When it applies: as soon as you want to call the API in test or production. Concrete example: GET /api/getServices?key=YOUR_API_KEY returns the live catalogue. Drawback: keep the key secret — it authorises real orders against your balance. Next step: sign up, copy your key, and fire the first read-only call.

The live rate table above shows every service with its API name, the base rate per 1,000 units, and the volume tier at which the rate steps down automatically — those thresholds are built into our billing, not a promo. The numbers come from the same pricing system the retail site uses, and your partner discount applies on top, per key. When it applies: budgeting your margin before you integrate. Concrete example: the per-1K rate in the row is what the order costs you through the API — your markup on top is your business. The honest limit: higher sustained volume is priced per partner rather than published, because we quote what we can actually hold for your profile. Next step: compare a row against what your current upstream charges you per 1,000 for the same delivery.

The trial bucket is 60 requests per second, which is enough to integrate, test and run normal reseller volume. Higher sustained throughput is available to partners and is set by request rather than published as a fixed number. When it applies: bulk status polling or high order-creation bursts. Concrete example: poll order status on a sensible cadence rather than hammering /api/getOrders in a tight loop. The honest framing: we quote real limits per partner instead of advertising a headline number we cannot guarantee for everyone. Next step: tell us your expected peak when you request access.

Most "SMM panels" are middlemen: they buy capacity from another panel and re-sell its endpoints with a markup, so they cannot fix delivery, set the refund path, or tell you the real order status — they are polling their own supplier. Streamrise owns the controller that runs every order, retail and API alike. When it applies: any time delivery quality and a real refund SLA matter to your customers. Concrete example: when an order needs intervention, it is our engineers on the same system, not a support ticket forwarded to an upstream you cannot see. The honest limit: being the source means we will not promise outcomes we do not control. Next step: compare the source-vs-middleman table above.

A single key covers both Twitch and Kick — viewers, followers, views and chatters across the families the backend exposes. The same key, same balance and same endpoints work for either platform; you address a service by its name (e.g. twitchViewers) or its numeric PerfectPanel ID. When it applies: you resell more than one platform and do not want two integrations. Concrete example: create a Twitch viewers order and a Kick followers order through the same /api/newOrder endpoint, only the service value changes. Next step: call /api/getServices to read every service available to your key.

API orders share the same controller and the same refund path as retail orders — there is no second-class API queue. If an order is not delivered as described, the refund follows the same policy your retail customers would get. When it applies: any order that under-delivers on our side. Concrete example: a partially delivered order is reconciled through the same refund mechanism, not parked on an upstream supplier's balance you cannot reach. The honest limit: we publish incidents rather than advertise an uptime percentage we cannot promise per-account. Next step: ask for the partner SLA terms in writing before you go live.

Yes to PerfectPanel — a single POST /perfectPanel endpoint switched by an "action" field (services, balance, status, add, cancel), a drop-in for software that already speaks the protocol, plus richer native /api/* endpoints. Real-time updates are live over WebSocket: connect to wss://stream-rise.com, send your key as the first message, subscribe to ordersUpdates, and order statuses are pushed as they change — the same feed our own panel runs on, with /api/getOrders polling as the fallback. When it applies: migrating an existing PerfectPanel integration, or building a status-driven dashboard without a polling loop. Concrete example: point your existing panel software at /perfectPanel and your services, balance and add-order calls work unchanged, while the socket feeds your status column. The honest limit: classic HTTP webhooks — a POST to your URL — are still on the roadmap, and there is no idempotency key yet, so check /api/getOrders before retrying a write. Next step: read the full API reference for the request and response shapes.