In a provider's price list every item looks the same: a name, a price per 1000, a minimum and a maximum. But they are not ordered the same way. Some services need a list of comments on top of the link, some need an author's username or a set of hashtags, and a few must not receive a quantity at all. Panel owners usually learn this the painful way: order rejected, money gone, customer waiting.
Where the service type comes from
The provider states it — the service list response carries a type next to the price and the limits. It isn't decoration: the type decides which parameters the order method will accept. A panel that ignores the type and sends a link plus a quantity for everything only works on the largest category and collects errors everywhere else.
In the real provider catalogs we work with the split looks roughly like this: about 6,200 ordinary items, around 220 with custom comments, some 200 subscription items, about 160 packages, and a long tail of a few dozen each. So 90% of a catalog really is simple, and the trouble comes from the remaining 10% — which is often where the best margin sits.
Which parameters each type accepts is laid out in the reference on SMM panel API methods, along with the batch response shapes and the numeric lookups the service list never returns.
Default — the type your catalog rests on
The ordinary type: a link to a post or profile plus a quantity. Followers, likes, views, reactions all live here. The price is per 1000 units and the customer picks a volume between the item's minimum and maximum.
What breaks here is not the format but the link: a private profile, a profile link where a post link was needed, a shortened link from a mobile app, a link stuffed with tracking parameters. Validating link formats inside the panel removes a visible share of support tickets — the customer sees a hint before paying instead of a "rejected" status after.
Custom Comments and everything that needs text
Custom comments are the second largest category. The customer supplies not a quantity but a list of comments, one per line. The volume comes from the number of lines rather than a separate field — and if the panel sends its own quantity, the provider rejects the order.
- Line count equals order volume. The price follows it too, so the quantity field shouldn't be shown — it should be calculated.
- Empty lines and duplicates. Strip them before sending: providers treat them differently, and the customer counts the lines they typed regardless.
- Neighbouring types. Mentions, hashtag and keyword-based services need fields of their own — an author's username, a hashtag list, a search query.
Package: the volume is baked in
Package services are sold whole: "1000 followers" is the service itself, not a service you pass 1000 to. There is no quantity to send, and sometimes it must not be sent. The price is per package rather than per 1000, so a panel that applies the usual formula shows the customer the wrong total.
Packages suit beginners — picking a ready set is easier than typing a volume. But in the catalog they need an honest description: what's included, how long it takes, whether a refill applies.
Subscriptions: an order that doesn't exist yet
The hardest type. The customer points at an author instead of a post, and from then on the provider watches for new publications and creates an order for each one. Neither the number of posts nor the final amount is known up front.
For a panel that means a separate entity: a list of active subscriptions, their statuses, a way to stop them — and a billing model for a total you can't know at the start. Until that section exists for real, such items are better left unsold: selling a subscription without showing the customer what's happening on it leads straight to refunds. That's exactly why they don't reach our catalog yet.
What a panel owner should do about it
- Don't list what the panel can't order. A catalog item is a promise. If the type isn't supported, the item has no business being on the storefront.
- Test every new type with your own money. A minimum order per type is cheaper than an argument with a customer.
- Watch the rejected orders. A cluster of rejections in one category almost always means the service type is handled wrong, not that the provider is bad.
- Remember the money. A rejected order doesn't always refund itself — the panel needs its own logic for returning funds to the customer's balance.
Wrap-up
Service types are the part of a panel you can't see in the interface and can't fix with design. Either the panel knows which parameters each item accepts, or a slice of the catalog quietly doesn't work. At SMMPanelRent the type arrives together with the item from the provider's catalog, the order form and the API docs are generated from one registry, and unsupported types never go on sale. You can check all of it without a budget: orders through our own catalog don't count toward the plan at all, and with third-party providers the first hundred orders a month are free.
