Webhooks or polling? Build an order tracker that can recover

Yes, some SMM panels support webhooks, but most Perfect Panel-style APIs do not, so status has to be polled. NotPanel's standard key + action API (the same /api/v3 that panels already speak) sends signed webhooks: up to 5 HTTPS endpoints per account, 8 events from order.processing to refill.rejected, an HMAC-SHA256 signature on every delivery, and up to 8 delivery attempts over 24 hours.

Use webhooks for routine order changes and keep status polling for reconciliation: checking that your records still match the panel. If you are building a small integration without a reliable public receiver yet, start with batched polling. Add webhooks when you can verify, save, and process their deliveries reliably.

The real question is what your customer sees after a change. An order may finish while your application is restarting, or a refund event may arrive twice because the first acknowledgement was lost. A useful order tracker handles both situations without showing stale information or applying the same update twice.

Give each method a clear job

Polling: ask for the current picture

Your application sends action=status and receives the state at that check. It is straightforward to start with, and multi-status accepts up to 100 order IDs per request. A shorter interval means more requests, including checks where nothing changed.

Webhooks: receive selected changes

NotPanel sends events to a registered HTTPS endpoint. Your receiver handles incoming work instead of repeatedly asking about every order. Deliveries do not use your client’s status-request allowance; your own receiver still needs capacity and monitoring.

Reconciliation: repair missing information

After an outage, or when a record looks stale, fetch current status for the affected orders. Keep this with webhooks: event notifications are best effort, an event can be missed, and delivery is not guaranteed. Retries are finite.

What the NotPanel API actually sends

Add an endpoint on your dashboard’s API page or with webhook.add. Use a publicly reachable HTTPS URL and choose the events you need, such as order.processing, order.in_progress, order.completed, order.partial, order.canceled, order.cancel_refused, refill.completed and refill.rejected; the webhook reference lists them all. Save the secret securely: it is shown once, and webhook.list never returns it. Use webhook.list to inspect your endpoints, webhook.test to send a ping to your receiver, and webhook.remove to remove an endpoint.

Each delivery carries one event in a small envelope: id, type, schema_version, created_at, sequence and data. data.order has the same fields as an action=status reply. The abbreviated example below shows the shape, not a live order.

{
  "id": "EXAMPLE_EVENT_ID",
  "type": "order.completed",
  "schema_version": 1,
  "created_at": "2026-10-10T12:30:00Z",
  "sequence": 1042,
  "data": {
    "order": {
      "order": 7001,
      "status": "Completed",
      "status_key": "completed",
      "remains": "0"
    }
  }
}

Read the event type from the verified body. X-Webhook-Event is also sent, but it is not signed. Endpoints added on the dashboard and through the API receive the same envelope.

Make receiving an event safe

1. Keep the raw body. Verify X-Webhook-Signature using the endpoint secret and X-Webhook-Timestamp, then enforce your receiver’s chosen timestamp tolerance. Parsing and reconstructing the body can change the signed bytes.
2. Log X-Webhook-Delivery-Id to track attempts; it stays the same on every retry of that delivery. Save the verified event before acknowledging it with a 2xx response. If you cannot safely accept it, let the sender retry rather than returning a success that loses the event.
3. Process each event id once. Keep duplicate detection durable across restarts and coordinate it with the order update. The same event id reaches every endpoint subscribed to it, so delivery-level duplicate detection alone is not enough.
4. Do slower work after acceptance. A valid signature establishes authenticity, not event order. Use sequence to put events in order, and when a delayed event conflicts with a newer state, reconcile with status instead of blindly replacing the customer’s current view.

Follow the signature verification walkthrough

What happens when your endpoint is unavailable?

A timeout (10 seconds) or a non-2xx reply is a failed attempt. NotPanel tries each delivery up to 8 times over 24 hours: at once, then 1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours, 12 hours and 24 hours after the event. It pauses the endpoint after 50 failures in a row or 3 days without a success, and the account owner is notified. A successful delivery resets the failure count. Monitor webhook.list; silence alone does not prove that no orders changed.

Keep a scheduled reconciliation pass over unresolved or stale orders. Batch up to 100 IDs, respect the account’s response headers and rate limits, and use the results to repair your own records. After fixing a paused receiver, resume the endpoint in the webhooks section of your dashboard’s API page, which clears its failure count. Alternatively, remove it with webhook.remove, add the repaired HTTPS URL again with webhook.add and the intended events, store the new secret securely and update your receiver to verify with it. There is no public API action to resume an endpoint. Deliveries queued when it paused are not replayed, so reconcile missed order statuses with status.

Test the cases that a successful demo misses

Use synthetic payloads and a secret created for your own tests. No customer orders are needed to exercise receiver behaviour.

• Send the same verified delivery twice: one customer update should result.
• Deliver the same event twice with a restart in between: the event should still be recognised.
• Alter one byte or use an old timestamp: verification should fail under your chosen policy.
• Simulate an outage and a delayed event: a status check should restore the current order view.

The same broad practices—subscribe selectively, verify secrets, and acknowledge promptly—appear in GitHub’s webhook guidance. Header names, payloads, and retry limits here follow NotPanel’s contract, not GitHub’s.

Frequently asked questions

Do any SMM panels support webhooks?

Yes. NotPanel sends signed webhooks on its standard key + action API: register up to 5 HTTPS endpoints with webhook.add, choose from 8 events (order.processing, order.in_progress, order.completed, order.partial, order.canceled, order.cancel_refused, refill.completed, refill.rejected), and verify X-Webhook-Signature (HMAC-SHA256). Keep a status poll for reconciliation, because retries are finite.

Can I use only polling?

Yes. Batch status requests and choose an interval that fits your order volume and rate limits. Webhooks are useful when you can operate a reliable receiver; they are not required to place or track orders.

Do webhooks mean instant delivery or exactly one callback?

No. Network delays and retries can affect arrival, and duplicate deliveries can occur. Verify each delivery, process each event once, and keep status reconciliation for recovery.

Which headers should my API webhook receiver check?

Check X-Webhook-Signature and X-Webhook-Timestamp, then read id, type and data from the verified body. Use X-Webhook-Delivery-Id only to track attempts.

Does a webhook make an uncertain add safe to repeat?

Webhook delivery and order placement are separate problems. Keep the original request_id and unchanged parameters when retrying an uncertain add, then save the order ID it returns.

Keep these references nearby: webhook contract · order status · timeout recovery.