Changelog

v3.2: A new order system: one error list, simpler drip-feed, clearer cancel and refill

Everything below ships together under the header X-NotPanel-API-Version: 2026-10. Every earlier action keeps working, and the /api/v1, /api/v2 and /api/v3 addresses behave identically.

• Every order has one number that works in the dashboard, in support and in the API. API orders keep their old numbers.
• Drip-feed: runs with interval still works. The new simple form takes the total quantity and drip_feed_total_minutes, up to 48 hours.
• Cancel is instant with a full refund during the first 15 seconds. After that you can request a cancel where the service supports it, with an automatic refund. order returns one object, as before; orders returns an array.
• Refill works once every 6 hours per order, with no end date and a clear reason when it is refused.
• Telegram reactions are one reactions field, either a mix (👍,❤️,🔥) or exact counts (👍:60,❤️:40), checked before you are charged.
• The service list shows tags, extra fields with limits, drip-feed limits and availability. cancel: true now means cancel requests really work.
• Every error has a fixed code, an HTTP status and a retryable flag. The earlier codes and the current ones are listed below.
• New order_details, which can also find an order by your request_id.
• status carries the refund: for a canceled or partial order, refund is the refunded amount, so no separate call is needed. refund_quote is an earlier name that returns the same reply as status.
• Webhooks are one system now: one signed event per call, versioned, with new events for canceled and partial orders and for refill results.
• Removed: batched webhook bodies, the coupon parameter, and from status the refund_pending fields and the two refund policy fields. The old delay parameter is no longer read; use drip_feed_total_minutes.
• Added: can_cancel in status and instant_cancel_until in the reply of add. The earlier cancel_available stays in both, and cancel_window_seconds and cancel_before stay in the reply of add.
• Kept: the catalog and account_status actions keep working as before, and catalog is now documented under List services. Earlier parameter names still work: referer, lpost_count, hashtag for hashtag lists, comma-separated usernames and the earlier reactions map. webhook.add also accepts the event names order.refunded and order.refill_completed.
• /api/v1, /api/v2 and /api/v3 all keep working and behave the same. /api/v3 is the one documented.
• A completed order always shows remains as 0.

v3.1: Optional market-native service names

The services and catalog actions now accept an optional language code for localized service names using curated market terminology in ten supported languages. Curated market terminology preserves recognizable brands and product identifiers; admins can review or refine individual names. Explicit requests add canonical-name and actual-language metadata and safely fall back to English when a translation is missing or stale. Requests without language keep the legacy English response shape unchanged; numeric service IDs remain the stable integration key.

v3.0: v3 becomes the default API

Promoted /api/v3 as the canonical endpoint and made the familiar reseller contract a direct base-URL replacement. v3 adds optional caller-controlled idempotency, 60-second protection for identical legacy adds, the advanced catalog, numeric order and refill IDs, refund_quote, account_status, single or sequential bulk cancellation with the unchanged 15-second ordinary-order window, batch status and refill, and signed webhooks. API throughput now uses a lifetime-successful-spend tier and one rolling 60-second account bucket shared by every key. /api/v1 and /api/v2 are exact aliases of the same current contract.

v2.5: Advanced catalog, refund reconciliation, and cancellation

Added the paginated catalog and read-only refund_quote actions, expanded add and status metadata, and added a 15-second cancellation window for ordinary API orders. API webhook events now carry a stable event id, while a deliveryId remains stable across retries of the same batch; each retry gets a new timestamp and signature. Webhook delivery remains best-effort with retries, not a durable at-least-once guarantee.

v2.4: 12 new media platforms in the catalog

Added services for Google, Rumble, Audiomack, Tumblr, Kwai, Clubhouse, Vimeo, Deezer, Tidal, Apple Music, Quora, and GitHub. They appear in the services action like any other service and each has a dedicated public platform page. No client changes required — new service IDs simply show up in the catalog.

v2.3: Service availability enforced on add

Unavailable services reject action=add instead of silently accepting or queuing a new order. Refresh the catalog and choose an available service before retrying.

v2.2: Optional order parameters

The add action now accepts supported service-type-specific optional fields, such as a start delay and per-type engagement options. Fields already defined by a service type keep their documented meaning.

v2.1: Drip-feed parameters on order placement

The add action accepts runs and interval together for services with dripfeed=true. Total delivery is quantity × runs and cannot exceed the service maximum. Non-drip services reject these fields.