Webhook

Webhook is a mechanism by which a server sends a message to an address you control when something changes, so you learn that an order moved without asking for it.

In integrations that offer one, a webhook works the same way everywhere. You register a URL, the service sends a request to that URL when an event happens, and your software reacts when the message arrives rather than on a timer. A status change reaches you close to the moment it is recorded, and orders that are not moving cost you nothing to watch.

The API documents these panels publish describe no webhook, callback or push mechanism. The document ships with Perfect Panel, the software the ten in the set run, and the reading behind this is at /do-any-smm-panels-support-webhooks/, where all ten documents in the set were read on one day and found to be one document. The published actions ask questions and return answers: the catalogue, an order's status, the balance, a refill or cancel request. Nothing in that layout sends anything to you on its own. Status therefore has to be polled, which means your software asks about each open order on a schedule and compares the answer with what it stored last time.

Two things follow for anyone building on a panel API. Everything you would have hung on a webhook has to live in a polling loop instead, including refunds worked out from a partial order and any notice you pass to your own customers. And if a panel does advertise callbacks, it is doing something outside the common convention, so read its API page and test the mechanism on small orders before you build anything that assumes the message will arrive.

Nothing you can switch on

There is nothing to switch on from the buyer's side. Pointing your own software at a URL achieves nothing unless the panel is built to call it, and no configuration on your end turns a request-and-answer API into one that pushes.