How to Test an SMM Panel API Integration with Sandbox Keys
SMM panel API test plan: use sandbox keys with play money to cover every status, cancel, refill, errors and webhooks before you go live.
An SMM panel API test starts with a sandbox key. It runs the same calls as a live key with play money, and orders move through real statuses without reaching a supplier. Work through a test plan that covers every status your code must handle, then swap in a live key and repeat with one small real order.
Most integration bugs don't show up on a happy-path order. They show up when an order closes as Partial and your panel forgets to refund your customer, or when an error message arrives in a shape your code didn't expect. A sandbox lets you trigger those cases on purpose.
Why test in a sandbox instead of with small live orders?
| Sandbox with a test key | Small live orders | |
|---|---|---|
| Cost | Play money | Real money, even if small |
| Reaches a supplier | Never | Yes |
| Can you choose the ending | Yes, through the link | No, you get whatever happens |
| Partial and canceled cases | On demand | Only if a supplier happens to fail |
| Tests real delivery quality | No | Yes |
Use both, in that order: the sandbox to prove your code handles every branch, then a few small live orders to see real start times and delivery.
How does the Orbismm sandbox work?
- Test keys. Create one in the panel under API and webhooks, in the Sandbox view. Test keys start with
orb_test_. - Same URLs, both APIs. A test key works on
https://orbismm.com/api/v2andhttps://orbismm.com/api/v1without any other change. - Play money. Orders are charged at your own rates from a separate sandbox balance that never touches your real one. API v1 can reset it with
POST /v1/sandbox/reset; the v2balanceaction shows it when called with a test key. - Real checks. Service, link, quantity limits, drip-feed support and balance are checked exactly as on live orders.
- Nothing leaves. Sandbox orders never reach a supplier. Test keys only see sandbox orders and live keys only see live ones.
- Pick the ending. A link containing
partialends Partial with half delivered and half refunded; a link containingcancelis canceled before it starts with a full refund; any other link completes.
Sandbox orders move on their own over a few minutes. The exact timings, with example requests, are on the sandbox docs page.
What should an SMM API test plan cover?
Run each row with a test key and tick it off only when your own panel shows the right result to your customer, not just when the API answers. Messages are shown as API v2 returns them.
| Test | How to trigger it | Expected from the API | What your side should do |
|---|---|---|---|
| Connection | action=balance | balance and currency: USD | Show the provider balance |
| Service import | action=services | List with rate, min, max, refill, cancel, dripfeed | Store IDs, rates and flags |
| Completed order | add with an ordinary link | order ID; status Processing, In progress, then Completed; remains 0 | Mark completed, show start count |
| Partial order | Link containing partial | Status Partial, remains at half, charge reduced | Refund your customer the undelivered part |
| Canceled before start | Link containing cancel | Status Canceled, full refund | Refund your customer in full |
| Manual cancel | action=cancel on a running order of a cancellable service | cancel: 1, then Canceled or Partial | Handle both endings |
| Cancel a closed order | action=cancel on a completed order | The order is already closed. | Show a clear message, change nothing |
| Refill | action=refill on a completed order of a refill service, then refill_status | refill ID; In progress, then Completed | Show refill progress |
| Refill too early | action=refill on a running order | Refill becomes available when the order completes. | Hide or disable the button until completion |
| Validation errors | Wrong service ID, quantity outside limits, runs on a non-drip-feed service | Incorrect service ID., Quantity must be between … and …., This service does not support drip-feed. | Show the message; never charge the customer |
| Low balance | An order larger than the sandbox balance | Not enough funds on balance. | Alert yourself; don't lose the customer's order |
| Bulk status | status with orders=ID1,ID2,999999 | One entry per ID; the unknown one has Incorrect order ID | Update the known ones, log the rest |
| Wrong environment | A live key asking about a sandbox order | Incorrect order ID | Keep live and test keys apart in config |
The sandbox doesn't produce every state. Orders move straight to Processing, and refills aren't rejected. Your code should still handle Pending, a Rejected refill and any error message it doesn't recognise, because live orders can produce them.
What extra tests does API v1 need?
- Idempotency. Send the same
POST /v1/orderstwice with the sameIdempotency-Key. The first answers201; the retry answers200withIdempotent-Replayed: trueand the same order, and nothing is charged twice. The same key with a different body returns409 idempotency_conflict. - Batch orders. Send a batch with one valid and one invalid item to
/v1/orders/batch. Each item succeeds or fails on its own; check that your code reads results byindex. - Webhooks. Add an endpoint with a test key. Sandbox events are signed the same way as live ones and carry
livemode: false. Verify theOrbismm-Signatureheader, and use the endpoint's test event to check delivery. - Scopes. Call an order endpoint with a key that only has
read, and confirm your code handles403 missing_scope.
How v1 differs from v2 and when each fits is covered in our guide to SMM API v1 vs v2; signature details are in the webhooks docs.
How do you go live after testing?
- Create a live key with the same scopes and swap it in for the test key. Nothing else in the calls changes.
- Add your webhook endpoints again in the Live view. Each gets its own signing secret; update your server with it.
- Top up your balance. Live orders are charged from it and go to real suppliers.
- Place one small real order on each service you sell and compare its start with the service's median start time.
- Watch the first day of real orders closely, especially refunds on Partial and Canceled orders.
If you are connecting a panel script rather than writing code, adding a provider to your SMM panel covers the setup, and the API v2 reference lists every action. The rate limit is 60 requests per second per key by default.
From Orbismm order data
From Orbismm order data: once live, your orders join still being measured placed in the last 30 days, with a median start time of still being measured across 0 services.
Create a test key and follow the [sandbox docs](/docs/v1/sandbox).
Frequently asked questions
- Is there a sandbox or test mode before I connect my real panel?
- Yes. Orbismm test keys run full order lifecycles with play money on both API v2 and v1, and never place real orders.
- How do I test a partial or canceled order?
- In the Orbismm sandbox, put partial in the link to get a Partial ending, or cancel to get an order canceled before it starts. Any other link completes.
- Can sandbox orders affect my real balance?
- No. Sandbox orders use a separate play-money balance, never reach a supplier, and are invisible to live keys.
- Do webhooks work in the sandbox?
- Yes, on API v1. Endpoints added with a test key receive sandbox events, signed the same way as live ones and marked livemode false.
- What changes when I switch from a test key to a live key?
- Only the key. Add your webhook endpoints again in the Live view with their new secret, top up your balance and place one small real order to confirm.