SMM Panel AuditContact

What a child panel is, and when it makes more sense than an API integration

I co-founded an SMM panel and still run it, so most of my working day happens on the side of the market that buyers never see: provider connections, balances held at other panels, service mapping and the tickets that come from all three. A question I hear often from people who want to start selling is whether to buy a child panel or build something connected by API. This guide names no panels, quotes no fees and does not recommend buying a child panel from anyone.

What a child panel is

A child panel is a panel website that another panel, the parent, builds and runs on your behalf. It arrives already connected to the parent's service list. You bring a domain and a name, set your prices and open it to customers. From the outside it looks like any other panel, and in business terms it is one way of becoming a reseller.

What the owner gets, and what stays with the parent

The owner of a child panel usually gets:

What stays with the parent is everything underneath. The parent runs the panel software and decides when it changes. It hosts the site, so uptime and the database are in its hands. It supplies every order, because the child panel is wired to the parent's services. And it controls the service list: which services exist, what they cost at the parent's rate and whether they stay switched on.

The parts the owner holds are the parts customers see. The parts the parent holds are the parts that keep the site working.

How an order moves from a child panel to its parent

A customer tops up a balance on the child panel and places an order with a service, a link and a quantity. The child panel charges that balance at the owner's price.

The child panel then places the same order at the parent through the parent's API, using the owner's key. The parent treats it like any other API order and charges the owner's balance there at the parent's rate. The owner's margin is the gap between the two charges.

From there the parent sends the order to its own provider, which may be a supplier or another panel. Status updates come back down the same way, ending in the customer's order history.

Two balances are involved, and they are separate. Customer money sits on the child panel. The owner's working funds sit at the parent. If the owner lets the parent balance run dry, orders can fail to forward even though customers paid in full, and fixing that is the owner's job.

The other route: your own panel, connected by API

The alternative is to run panel software yourself, either hosted by you or rented as a hosted service, or to add reselling to a panel you already operate. You then connect one or more providers by API. Each connection is an address, a key and a balance, and each service in your catalogue is linked to one provider and one of that provider's service IDs.

Orders still travel upstream in the same way. The difference is that you choose the providers and can point each service at a different one. When a provider slows down, raises a rate or stops delivering, you move that service elsewhere without changing anything your customers see.

That flexibility costs work. Someone has to import and rename services, keep prices in line with several providers' rates, watch several balances and chase refills with whichever provider handled an order. Rented software still sits on someone else's servers, so read its terms too, but that vendor is not also your source of supply.

When does a child panel make more sense?

A child panel fits when you want to start selling without doing development or hosting work. There is nothing to install, no server to maintain, and the catalogue is usable on the first day.

It also fits when you are starting small and one supply source covers what you plan to sell. If your customers want a narrow set of services and the parent handles those well enough, a second provider adds work without adding much.

The strongest case is testing. If you do not yet know whether you can bring in customers at all, a child panel lets you find out before committing to software, integrations and several provider balances.

When does an API integration make more sense?

An API integration makes more sense once you need more than one provider, for example because a single source is weak on some services.

It suits owners who want to switch supply per service without asking anyone, and who want control of the catalogue: which services appear, how they are described and what sits behind each one.

It also suits owners who care about the data and the customer relationships. On your own panel the order history, customer list and links stay with you, and no single parent can end the business by changing its mind.

What to understand before buying a child panel

The parent sees every order and every link. It knows which accounts your customers promote and how much you sell.

The parent can change or disable services and rates. A service your customers rely on can be repointed at a different provider or switched off, and your catalogue changes with it.

Price changes may not flow through to your prices automatically. On some setups your price follows the parent's rate with a markup. On others it is a fixed figure you entered, and a rate rise upstream can leave you selling below cost until you notice.

Many setups carry recurring fees on top of the balance you keep at the parent. On some, adding other providers is restricted or not possible. And if the parent stops, the software, hosting and database may go with it. Ask in writing whether you can export customers, balances and order history, because customer balances are money you owe whether or not the site stays online.

What should a buyer ordering on a child panel know?

If you order on a child panel, you are one more step from supply than the parent's own customers. The price you pay carries the owner's margin on top of the parent's, a stacking described in why SMM panel prices differ.

Support gets passed upstream. The owner usually cannot see the delivery and has to raise your ticket with the parent, which may have to ask its own provider. Each handoff adds waiting time.

Nothing on the site says it is a child panel. A common sign is a catalogue identical to another site's, with the same service names, descriptions and limits, only at different prices. That is not proof, but it suggests the site does not choose its own supply, and the terms you can hold it to are the ones it publishes itself.

The limits of this measurement

This guide describes how child panels and API integrations are commonly set up, based on the author's work operating a panel. It does not compare child panel offers, fees or contract terms, does not assess any parent panel or software vendor, and does not estimate whether selling through either route can be profitable. What an owner controls, what a parent can see and change, and what happens when a parent stops providing the site all vary between setups, so the points here are things to check in a specific agreement rather than a description of every one.

Frequently asked questions

What is a child panel in SMM?

A child panel is a ready-made panel website that a parent panel sets up and runs for you. It comes connected to the parent's services, and you add your own domain, name and prices. Customers order on your site, and each order is forwarded to the parent and paid from your balance there, so the parent remains the source of supply.

Who owns the customers on a child panel?

The customer accounts and balances appear under your brand, but on a child panel they are stored in software and on servers the parent runs. Day to day that makes little difference. It matters when the relationship ends, so ask before buying whether you could export customers, balances and order history, and in what form, if the parent stopped providing the site.

Can I add other providers to a child panel?

It depends on the setup. Some child panels can only send orders to the parent, since being your source of supply is the reason the parent offers the product. Others allow extra providers, sometimes with limits. If you expect to need a second source for some services, confirm this in the terms before paying, because it decides whether you can ever switch supply per service.

What happens to a child panel if the parent panel shuts down?

Because the parent runs the software, the hosting and the supply, the site may stop working when the parent stops providing it. Orders cannot be forwarded, and the database may be out of reach. Your customers' balances are still money you owe them. Before buying, ask in writing what notice you would get and whether customer and order data can be exported.

Do child panel prices update when the parent changes its rates?

Not always. On some setups your price is a markup that follows the parent's rate, so a rise passes through to customers. On others you enter a fixed price per service, and a rate rise at the parent is charged to your balance while your customers keep paying the old price. Check which method your setup uses and review rates regularly.

Do I need coding skills to run my own panel instead of a child panel?

Not necessarily. Rented panel software removes most of the hosting and development work, and providers are usually added by entering an API address and a key. What remains is operating work: mapping each service to a provider's service ID, keeping prices in line with several rates, watching balances in several places and handling refills and refunds with each provider.

How can I tell if the panel I am ordering from is a child panel?

The site will rarely say so. A common sign is a catalogue that matches another site's, with the same service names, descriptions and limits at different prices. That is not proof, because resellers can import the same list and look much the same. Either way, judge the site by the refill, refund and support terms it publishes itself.