List your panel

Listing your panel, step by step

It is one sitting of about ten minutes, and you can stop at any point and come back — the account you open on the first step is what holds your place, and it is what you sign in to afterwards to see every figure we hold about you. Nothing on this list is a formality: each step either proves something we would otherwise have to take on trust, or tells you exactly what it costs you to skip it.

1. 1.Your account. One account holds every panel you run here, and it is what you sign in to afterwards.
2. 2.Your panel. The domain, and the read-only API key we price your catalogue from.
3. 3.Prove the domain. One DNS record. It is what puts a named owner behind the listing, and it is free.
4. 4.Badge (optional). Optional, and worth no points. Put our verdict on your own site if you want to.
5. 5.Plan. The free listing is fully eligible for every ranking. The paid plans change other things.
6. 6.Payment (optional). Crypto, confirmed by a person, with the transaction on the record.

The listing itself is free and stays free. Two of the steps are optional and one of them is the only one that costs anything; the flow tells you which, at the point where it matters, rather than at the end.

What we do with your API key

One call, on a schedule: action=services, the same request your own resellers make. It returns your public price list, and that is the whole of our use for the key. Everything else the SMM Panel API v2 can do — placing an order, reading order status, refills, cancellations, your balance — is code we do not run against your panel.

It is held on the server with owner-only file permissions, outside the database and outside every backup that leaves the machine, and it is not written into logs, audit entries or notification mail. The admin interface shows a twelve-character SHA-256 fingerprint instead, which is enough to tell two keys apart and useless to anyone who reads it. If we decline your listing the key is deleted rather than kept; if you rotate it in your own panel our next read simply fails, which is the control you should expect to have and the reason we ask for a key rather than a password.

What happens after you submit?

Two steps have already happened by the time you finish the flow: your key was tried against your own API the moment you entered it, and — if you published the DNS record — your domain was proved to be yours. So we start knowing the key works, how many services you sell, and that there is a named owner behind the listing. The rest is a verification pass, in this order. Nothing in it depends on what you tell us about your panel — the point of the sequence is that every claim is checked against an independent source, which is also why a panel cannot improve its score by describing itself better.

1. 1.Liveness and TLS. The domain has to resolve and serve a valid certificate. This runs daily thereafter and becomes the uptime signal.
2. 2.Domain age from RDAP. An independent lower bound on how long the panel has existed. A footer claiming a founding year earlier than the registration date is recorded as a discrepancy.
3. 3.Archive history. Corroborates the age signal and exposes multi-month gaps that suggest a relaunch under new ownership.
4. 4.Script fingerprint. Asset paths, headers and favicon hashes tell us which panel software you run, which implies your feature surface without us taking feature claims on trust.
5. 5.Catalogue sync. Accepting your listing starts the first full read of your service list through your key, and maps your rows onto our canonical service taxonomy so your prices become comparable. It repeats on a schedule from then on.
6. 6.Reputation check. Existing review-platform profiles, if any, read for review history spread over time rather than clustered.

You will get a reply within five working days either way. A new panel starts at unverified with unmeasured components shown as unmeasured rather than penalised. The reasoning is on the methodology page.

What gets a panel declined?

These are editorial lines rather than score thresholds, so no amount of good data elsewhere offsets them.

• Asking buyers for social account passwords or for OAuth with write scope, anywhere in the flow. A panel needs a public URL to deliver; a credential request has no delivery use.
• Services aimed at third parties. Downvotes, dislikes, negative reactions, negative or competitor reviews, and account or post mass-reporting. Several of these target private individuals, and we will not be the discovery layer for them.
• Review-buying as a core catalogue. Trustpilot, Google and app-store review services are excluded from the index for legal exposure reasons set out in our terms.
• An undisclosed rebrand or clone. If a panel shares an operator with one already indexed, we list it and disclose the relationship rather than presenting them as independent choices, because a buyer splitting a balance across two panels with one owner has diversified nothing.
• No API v2 endpoint, or a key that does not open it. The form says so immediately rather than leaving you waiting for a decline. If your API is compatible but lives at a path other than /api/v2, /api/v2.php or /api, email us the endpoint — that is a case we handle by hand.
• A domain that does not resolve, or a storefront with no reachable catalogue at all. We have found unregistered domains listed as live panels on competing directories; verifying the domain exists is the cheapest thing a directory can do and it is remarkable how often it is skipped.

Common questions