A reliable bulk-order workflow keeps one record per intended purchase, checks the batch before submission and reviews each result afterward. In NotPanel, start with Mass Order for compatible three-field orders. Keep retries attached to the same batch so a problem with two lines does not cause the other lines to be purchased again.
This guide covers the dashboard workflow first, then the additional decisions for API automation. It is a process you can use for a small agency list; you do not need to reach an arbitrary order count before keeping better records. Dashboard links require sign-in.
Prepare a batch someone else can check
Keep an agency-side list with your client reference, service ID, target, quantity, approval and eventual NotPanel order number. A spreadsheet can serve this purpose for a small supervised workflow. What matters is that two people do not unknowingly submit the same approved purchase and that accepted orders remain traceable.
Check each service in the current catalog. Confirm its input format, limits and price, and remove duplicates from your intended list. Separate orders that need custom comments, Telegram reactions or Speed: the three-field Mass Order format cannot express them, and Mass Order refuses services with required extra fields. Packages have a fixed size, so the typed quantity is ignored for them. Use New Order for the full form.
Download the sample and reconciliation template
- Mass Order sample (TXT): two lines in the supported three-field format. Service IDs are placeholders and example.invalid targets cannot receive real orders. Replace every field with an approved purchase before checking.
- Reconciliation template (CSV): an agency-side record, not a file to import into Mass Order. Keep intended purchases, accepted order numbers, placement outcomes, delivery status, actual charges and confirmed Wallet credits separate.
Neither download submits an order. The sample uses no real customer identifiers. Leave unknown outcomes unresolved until you can match them to Orders and Wallet history; do not infer a credit from a remaining quantity.
Validate at most 100 lines at a time
Open Mass Order and enter one order per line:
service_id | link | quantityReplace the three fields with the exact service ID, its required target link and a whole-number quantity. The vertical bar separates fields. Keep the batch to 100 nonempty lines or fewer: the current validator reads the first 100 nonempty lines, so split a longer source list before pasting it.
- Choose Check orders. Checking previews the list; it does not place orders.
- Review the valid count, errors, service names, quantities and total charge.
- Correct errors and check again, or deliberately submit only the valid rows.
- Check the final batch and available Wallet balance before choosing Place # orders, where # is the number of valid lines.
A service requiring extra inputs will direct you to New Order. A price preview is also not a reservation: service availability, pricing and account conditions are checked when each purchase is placed. Save the actual results rather than treating validation as proof of acceptance.
Read the result as individual purchases
The result shows how many orders were placed, how many failed to place and the total charged. Choose View orders to review accepted orders. A successful placement means an order exists; it does not mean delivery has finished.
Example: a batch has five valid lines. Three are placed and two fail to place. Keep those three order numbers. In the same result screen, Retry failed orders resumes the existing batch’s remaining failures. Do not copy all five into a fresh batch to repair the two failures.
Start a new batch starts a fresh submission. If a connection drops before you see a result, keep the current batch and inspect Orders before starting over. An unknown result is different from a confirmed rejection. The timeout recovery guide explains that distinction for API clients.
Separate placement, delivery and money in your handoff
After placement, link each accepted order to its client reference. Track delivery in Orders and charges or confirmed credits in Wallet history. A changing remaining quantity describes progress; it does not independently confirm a Wallet refund.
Use the average start-time guide when choosing services for a schedule. Each order can start at a different time, and a start estimate is not a completion deadline for the whole batch.
Each order keeps its own 15-second free-cancel window. After that, you can request a cancel on services that support it, and the undelivered part is refunded automatically once the cancel is confirmed. Bulk ordering extends neither. A Partially completed order refunds its undelivered remainder at that moment. For anything unresolved, follow the applicable refund and cancellation rules.
Automate the process after the decisions are clear
If manual submission becomes repetitive, give the developer your actual batch checklist and exception records. Your integration should preserve a reference for each intended purchase, record its accepted order number and recover unknown outcomes without creating fresh purchases automatically.
The add-order contract supports an optional request_id for caller-controlled retries; idempotency_key is the compatibility alias. Reuse the same explicit ID and parameters for the same purchase and you get the same order back. If the request changes but the request_id stays the same, the API returns REQUEST_ID_CONFLICT. After a timeout, order_details can find the order by request_id, so you can recover without placing a second purchase. Without an explicit ID, identical requests have a 60-second duplicate-protection window; that is not a substitute for your own purchase references.
Respect the documented limits and the response instructions. Use webhooks and status polling together so a delayed notification does not leave an order forgotten. Webhooks send one signed event per message, with events for canceled and partially completed orders and for refill results. There is no universal bulk throughput figure: the current account, action and service constraints determine how quickly a particular workload can proceed.
Close the batch with a short reconciliation
- Every intended purchase is matched to an order number or a documented reason it was not placed.
- Accepted charges are matched to Wallet records, separately from any later refund.
- Open orders have an owner and a next review time.
- Customer updates distinguish accepted, started, completed and under investigation.
- Unresolved questions keep their existing support ticket reference.
Keep this handoff concise enough that another team member can act on it. When an order needs attention tomorrow, the next person should know which purchase exists and what has already been checked.
Mass Order questions
How many orders can I enter in NotPanel Mass Order?
Enter no more than 100 orders per batch, one nonempty line per order, using service_id | link | quantity. Split a longer list before validating; the current validator reads only the first 100 nonempty lines.
Can Mass Order place orders with extra inputs?
Not directly. The three-field format has no room for extra details, so Mass Order cannot be used for services with required extra fields such as custom comments or Telegram reactions, and it cannot set Speed. Packages have a fixed size and ignore the typed quantity. Use New Order for those services.
What should I do if only some lines were placed?
Check the placed and failed counts and review Orders. Keep the existing batch and use Retry failed orders for its remaining failures. Starting a New batch is a fresh submission and can repeat lines that already succeeded.
Does bulk ordering extend the cancellation window?
No. Each order has its own 15-second free-cancel window. After that, a cancel is a request and works only on services that support it. A batch does not extend either one.
