Does an SMM panel check the link you paste?
Method: One order was placed on 4 September 2026 against one live Perfect Panel v2 API endpoint, the panel operated by the team that publishes this site, using the add action with service 2262, a quantity of 10 and the link "notaurl". The panel record gives the ID; the name is taken from this panel's catalogue as archived on 1 October 2026, where 2262 is listed as "Instagram Story Views (All Stories)". The response and the time were taken from the panel's own order record and from the developer's commits of the same day, and the order was read again on 13 October 2026. No website order form was used, and no other panel was sent a request. Read on 4 September 2026 and 13 October 2026.
The add call accepted the link "notaurl", returned an order ID and charged the balance, and the order was later reported completed with nothing returned.
Panels read: boostero.com.
Findings do not enter the rankings score.
A link is the one thing on an order that only you can get right. The quantity has a range the panel checks, the service has an ID the panel checks, and the balance is arithmetic the panel does for itself. The link is a string, and a string is whatever you typed.
On 4 September 2026 one order was placed through a live Perfect Panel v2 API to find out what happens when that string is wrong. The endpoint belongs to the panel operated by the team that publishes this site, which is the panel whose internal record this site can read in full. The call was the ordinary add action: service 2262, quantity 10, and for the link, the word "notaurl". The record of the order carries the ID and not a name; the catalogue archived on 1 October 2026 lists 2262 as "Instagram Story Views (All Stories)", at a rate of $0.006 per 1,000.
At 12:28:17 UTC the API answered {"order":12486264} and the balance was charged.
What the panel checks, and in what order
Three checks run before an order is accepted, and three requests show the order they run in. A request naming a service that does not exist is rejected on the service, before anything else is looked at. A request carrying a quantity outside the service range, the same unusable link and a total above the balance comes back naming the quantity. A request carrying the unusable link and a total above the balance, with the quantity inside the range, comes back naming the funds. Service first, then the quantity range, then the balance.
The link is not in that sequence at any point. It is carried, not inspected.
What happened to the order
The cancel call was sent and answered "Cancel unavailable. Try again later." Nothing else was done to the order.
Read again on 13 October 2026, it showed status completed, remains 0 and start count 0. The charge was not returned. The panel's record is what reports all three, and it reports an order that was accepted with a link that points at nothing, closed as finished, and paid for.
What this does and does not show
It shows one order, on one panel, through one API. It does not show how a website order form behaves, because no form was used, and it does not show what the other nine panels in the audit set would do, because none of them was sent a request for this finding. What is known about them is that they publish one API document because they run the same software, which is the finding published on 1 October. That document lists what the add call takes, a service, a link and a quantity, but says nothing about which of them is checked or in what order, so it cannot show whether any of these panels checks the link. Running the same software is not the same as having been measured.
The panel tested is this site's own, and that is the reason it could be tested at all: an order placed to see what a panel does with a bad link costs money, closes as completed, and leaves a record somebody has to be allowed to read. Doing that to another operator's panel without telling them is not a reading this site is willing to take.
What a buyer should take from it
Read the link back before you send it. Keep the order ID the call returns, because that is the only handle you have afterwards. Check the order yourself instead of waiting for the panel to tell you something is wrong, and do not assume a wrong link will be caught, refused or refunded: on 4 September it was accepted, charged and reported completed.
The limits of this measurement
This is one order on one panel, placed through the API and never through a website order form, so it says nothing about what a form checks before it submits. The panel is the one operated by the team that publishes this site, which is the panel whose record this site can read in full; the other nine in the audit set were not sent a request for this finding, and what is said about them here rests on their running the same software, not on a measurement of each. One order is one order: it shows that the link was accepted, charged and reported completed on that day, not how often that happens. The finding ranks nobody and enters no score.
Frequently asked questions
Does an SMM panel check the link you paste?
The one API tested on 4 September 2026 did not. The add call was sent with the link "notaurl", which is not a URL at all, and it answered with an order ID and charged the balance. The order was read again on 13 October 2026 and the panel reported it completed, with nothing returned.
What is validated, if not the link?
Three things, in this order: the service ID, then whether the quantity sits inside the service's range, then whether the balance covers the charge. Three requests show it. An unknown service is rejected on the service alone. A bad quantity with a bad link and too little balance comes back on the quantity. A bad link with too little balance, and the quantity valid, comes back on the funds.
Could the order have been cancelled?
The cancel call was sent and answered "Cancel unavailable. Try again later." The order stayed open and was later reported completed. On this panel, at that moment, the API offered no way to stop an order that had been accepted with a link nobody could deliver to.
What did the completed status say?
Read on 13 October 2026, the order showed status completed, remains 0 and start count 0. Remains 0 is what a panel reports when nothing is left to deliver, and a start count of 0 is what it recorded before delivery began. The charge was not returned.
Does this apply to every panel?
It was measured on one. The ten panels in the October 2026 audit set publish one API document because they run the same software, which is the finding published on 1 October. That document lists the parameters of the add call but does not describe how they are validated, so it cannot settle the question for any panel. Running the same software is not a measurement of each panel, and a panel can add a check of its own at any time.
What should a buyer do with this?
Treat the link as the one field nothing will catch for you. Read it back before you send it, keep the order ID the call returns, and check the order yourself rather than waiting to be told. A link that cannot be delivered to can still be accepted, charged and closed as completed.