SMM Panel API Integration: A Developer's Guide to the SMM API v2

This SMM panel API integration guide is for developers and panel owners who want to connect our services to their own panel, website, bot or app. It walks through the request format, the main actions, avoiding duplicate orders, handling errors and rate limits, and using webhooks instead of polling. For the business side of reselling, read the SMM reseller panel guide; this post focuses on the technical integration. The full reference lives in our API documentation.

How SMM Panel API Integration Works (SMM API v2)

Our API follows the widely used SMM panel API v2 format, so most panel scripts can add us as a provider with just two things:

• Endpoint: https://abisektamang.com/api/v2
• Your API key, created on the API access page in your account

Every request is a POST with your key and an action. The body can be form fields (application/x-www-form-urlencoded or multipart/form-data) or a JSON object sent with Content-Type: application/json. A GET with a query string also works, but it can leave your key in server logs, so POST is recommended.

Responses are JSON in UTF-8. Problems come back as {"error": "…"}, so check for an error field in every response. Amounts are strings in NPR with two to five decimals.

Step 1: Create and Secure Your API Key

1. Create an account and sign in.
2. Open the API access page and create a key.
3. Choose its permissions — for example, a key that can only list services and check status, and a separate key that can place orders.
4. Optionally restrict it to your server's IP addresses. Requests from other addresses get an error.
5. Store it safely. The key is shown only once.

Always call the API from your own server. Never put the key in a web page, mobile app or public repository. If a key leaks, rotate or revoke it on the API access page.

Step 2: Check Your Balance

The simplest test that everything is connected:

curl -X POST https://abisektamang.com/api/v2 \
  -d key=YOUR_API_KEY \
  -d action=balance

If you get a balance back rather than an error, your key and permissions work.

Step 3: Fetch the Service List

curl -X POST https://abisektamang.com/api/v2 \
  -d key=YOUR_API_KEY \
  -d action=services

Each service in the response includes:

• service — the ID you use when ordering
• name, category and type — the type tells you which parameters an order needs
• rate — price per 1,000 in NPR (or per order for package-type services), after any account discount
• min and max — allowed quantities
• refill, cancel, dripfeed — whether those features are available

Tip: cache the service list and refresh it on a schedule (for example hourly) rather than calling it on every page load. Rates and availability can change, so don't cache it forever.

Step 4: Place an Order

curl -X POST https://abisektamang.com/api/v2 \
  -d key=YOUR_API_KEY \
  -d action=add \
  -d service=1 \
  --data-urlencode "link=https://www.instagram.com/yourprofile/" \
  -d quantity=1000

The response contains the new order ID, and the cost is taken from your balance straight away. Key parameters:

• service — the service ID
• link — the public link to the profile, post or video. Never send a password.
• quantity — between the service's min and max
• runs and interval — optional drip-feed settings (number of deliveries and minutes between them)
• idempotency_key — your own unique reference for the order (see below)

Different service types (for example custom comments or packages) need different parameters; the API documentation lists them by type.

Avoid duplicate orders with an idempotency key

Networks fail. If your server times out after sending an order, you may not know whether it was placed. Send an idempotency_key — such as your own internal order number — with every add request. If you retry with the same key, you avoid charging your customer twice. The API also accepts client_key or external_id for the same purpose.

Step 5: Check Order Status

Use the status action to check an order. To stay efficient, check up to 100 orders in one request by passing several IDs, separated by commas or spaces, rather than one request per order. Typical statuses include Pending, In progress, Completed, Partial and Canceled. For partial and canceled orders, the undelivered amount is refunded to your balance automatically.

Step 6: Refills and Cancellations

If a service supports refills, your key (with the right permission) can request a refill and check its status with refill and refill_status. Services that support cancellation can be canceled with cancel. Always check the refill and cancel flags in the service list before offering these features to your customers.

Step 7: Use Webhooks Instead of Polling

Polling hundreds of orders every few minutes wastes requests. Webhooks let us call you instead:

1. On the API access page, enter one https:// address and you'll receive a signing secret.
2. Every status change of your orders and refills is then sent to that address as a JSON POST, usually within about a minute.

Events include order.processing, order.in_progress, order.completed, order.partial, order.canceled, refill.in_progress, refill.completed, refill.rejected and test.ping.

Verify every webhook

Each delivery includes X-Panel-Event, X-Panel-Timestamp, X-Panel-Signature and X-Panel-Delivery headers. To verify:

1. Read the raw request body.
2. Compute sha256= + HMAC-SHA256 of timestamp + "." + body, keyed with your signing secret.
3. Compare with X-Panel-Signature using a constant-time comparison.
4. Reject deliveries whose timestamp is more than five minutes old.
5. Use X-Panel-Delivery to ignore duplicate retries.

Answer with any 2xx status within 10 seconds and queue slow work for later. Failed deliveries are retried on a schedule over about a day, and a webhook that fails many times in a row is turned off, so monitor it.

Errors and Rate Limits

Common error messages include an invalid or missing key, an incorrect action, service ID or order ID, not enough funds, a quantity outside the allowed range, a key without permission for the action, and rate-limit messages.

Current limits per our documentation:

• 120 requests per minute per key
• 600 requests per minute per IP across all keys
• Too many invalid-key attempts from one IP within 10 minutes get temporarily blocked

When you hit a limit, wait for the number of seconds in the Retry-After header. Batch status checks and use webhooks to stay well inside the limits.

SMM Panel API Integration Checklist

• Key stored server-side only, with minimum permissions
• IP restriction enabled if your server has a fixed IP
• Service list cached and refreshed on a schedule
• idempotency_key sent with every order
• Every response checked for error
• Status checked in batches of up to 100, or webhooks enabled
• Webhook signatures and timestamps verified
• Low-balance alert so orders don't fail

Frequently Asked Questions

What format does your API use?

The standard SMM panel API v2 format, at https://abisektamang.com/api/v2.

Can I use JSON instead of form fields?

Yes. Send a JSON object with Content-Type: application/json.

What currency are rates in?

NPR, returned as strings with two to five decimals.

How do I prevent duplicate orders?

Send a unique idempotency_key with every add request.

Do you support webhooks?

Yes. Add an https address on the API access page to receive signed JSON events for order and refill status changes.

What are the rate limits?

120 requests per minute per key and 600 per minute per IP. Check the API documentation for the latest details.

Start Your SMM Panel API Integration

Ready to connect? Create your free account, generate an API key with the permissions you need, and follow the API documentation. If you are building a panel brand around it, our child panel guide and how to start an SMM business in Nepal cover the next steps.