Your customer submits an order. The connection times out before your panel gets the answer. Now you need to know whether the order exists, whether money was charged and whether pressing retry will create another purchase. That is where an API earns its place in a reseller business.
NotPanel API v3 gives those situations a documented path. It keeps the familiar reseller request format while adding practical ways to compare services, retry a purchase safely and explain what happened to its charge. New integrations use https://notpanel.com/api/v3.
What changed from v2 to v3?
The familiar key and action requests remain the foundation: list services, place an order, check its status and read the balance. A working integration should be able to keep doing those things as a panel adds more useful information.
NotPanel introduced improvements throughout the v2.x releases, including the advanced catalog and refund quote. v3 brings the extended contract together under the canonical endpoint. It also makes optional features easier to adopt alongside existing calls. The API changelog records that progression; these capabilities did not all appear on one launch day.
Choose a service with more than a name and price
A reseller often needs to answer a customer before accepting an order: is the service available, does it need custom text, and when does delivery normally begin? A long list of names and rates leaves that work to the person building the ordering form.
NotPanel keeps action=services for the familiar catalog array and offers action=catalog for richer discovery. It includes pagination, search, filters, account-priced rates, availability, platform and category information, and extra input requirements. Cancellation metadata and average-time evidence travel with the service.
Average time describes the expected start of delivery. It measures placement to the first observed positive delivery, rather than the time needed to finish the entire quantity. The response can include the timing sample size and whether the value is measured, estimated or unknown. An integration can show that distinction instead of presenting every number with the same confidence.
Optional service-name localization covers ten supported languages. The numeric service ID remains the stable reference. When requesting a language, read canonical_name for the English reference name and name_language for the language actually returned, including an English fallback when needed. The catalog is a discovery snapshot: the committed order response remains authoritative for the actual charge.
Retry the purchase you intended to make
Imagine a reseller order called shop-order-1042. The first submission succeeds, but its response never reaches the reseller. Sending the same logical request with the same request_id lets NotPanel return the already committed order and charge. The customer does not need a second purchase to discover the result of the first.
- 1. SubmitSend the order with request_id=shop-order-1042.
- 2. Response lostKeep the original request and retry identifier.
- 3. RecoverRepeat that request; receive the committed order without another debit.
Use a new identifier for a different order. Reusing one with changed order details causes a conflict, because the identifier belongs to the original request. The optional idempotency_key field is a compatibility alias; request_id takes precedence if both are supplied.
Older clients that send neither field receive 60-second protection for identical requests from the same account. This has a practical consequence: an intentional identical order inside that window also returns the first order. Give each intended purchase a unique request ID, or wait for the window to pass. The order submission reference explains the complete retry contract.
Explain a refund without guessing from the balance
A wallet balance alone cannot explain which order was refunded or whether a cancellation is still being confirmed. NotPanel provides action=refund_quote to read the relevant amounts and deadlines without changing the order or wallet.
| Customer question | What the ordinary-order quote exposes |
|---|---|
| What did this order cost? | The original charge |
| What has already reached my wallet? | The credited refund amount |
| Is recognized refund money still pending? | The pending refund flag and amount |
| Can I still cancel? | Current cancellation availability and its deadline |
| When does unresolved-order protection apply? | The seven-day deadline and applicable amount |
Ordinary orders have a 15-second cancellation window before dispatch and seven-day protection if they remain unresolved. Eligible subscription cancellations follow their own confirmation and settlement flow. A subscription marked cancelling may still be awaiting a final result; its refund should not be described as credited until the response confirms that credit. The refund policy explains the applicable scope.
Keep a reliable picture after the first response
Batch status and refill operations help a reseller reconcile multiple orders. Standard status labels stay familiar, while the additional status_key distinguishes states that need different next steps. Signed webhooks can bring order and refill changes to the integration as they happen.
Webhook delivery is best-effort with retries. Verify signatures, deduplicate events and keep status reconciliation for important changes. A notification arriving twice should not credit a customer twice. The webhook reference documents verification and delivery behavior; the error reference explains when to correct a request or retry, including the meaning of a supplied Retry-After header.
A practical first integration
Follow the quickstart, fetch the catalog and keep one request ID per intended purchase. Then build the screens your customer will actually need: order state, credited refunds and any remaining action. Adopt optional fields as those screens need them. Official SDK packages are not currently published; the reference includes HTTP examples and guidance for existing reseller clients.
Questions about NotPanel API v3
Can an existing v2 integration use NotPanel API v3?
Yes. NotPanel keeps the familiar form-encoded key and action contract. New integrations should use /api/v3. The /api/v1 and /api/v2 URLs are compatibility aliases of the same current contract, and the additional v3 actions and fields are optional.
How does NotPanel prevent a retry from creating a second order?
Send one request_id per logical order and reuse it with the same request when retrying. NotPanel returns the committed order instead of charging again. Without an explicit retry identifier, identical requests from the same account receive 60 seconds of duplicate protection.
Does the API average time mean order completion time?
No. Average time estimates the time from order placement to the first observed positive delivery. The advanced catalog includes timing evidence and sample size when available, so a reseller can explain the expected start separately from completion.
Does a refund quote issue a refund?
No. The refund_quote action is read-only. It reports applicable amounts, credited refunds, pending refund money and deadlines. A quote does not cancel an order or change the wallet balance.
Can webhooks replace every order-status check?
No. NotPanel signs webhook notifications and retries failed deliveries on a best-effort basis. Clients should verify signatures, deduplicate events and reconcile important state through action=status because arrival and delivery order are not guaranteed.