SMM Panel API Documentation & Reseller Integration Guide

Automating social media marketing at scale requires programmatic integration with SMM panel APIs. Resellers building automated storefronts, developers integrating SMM into existing marketing platforms, and agencies managing multi-client campaigns all benefit from reliable API access. This guide documents the TapprSMM API endpoint schema, request formats, authentication, response structures, error codes, status definitions, and webhook configuration.

1. API Endpoint and Connection Requirements

All TapprSMM API requests use a single endpoint: https://tapprsmm.com/api/v2. Every request must be an HTTP POST request with the Content-Type header set to application/x-www-form-urlencoded. JSON and multipart form data are not accepted. Every request must include your API key in the request body as the parameter key=YOUR_API_KEY.

Obtain your API key from the TapprSMM dashboard under Account Settings > API. Keep the key confidential. Never include the API key in client-side JavaScript files, public repositories, or frontend source code that could be accessed by end users. Rotate the key immediately if you suspect it has been exposed.

2. Authentication

TapprSMM uses key-based authentication. Include key=YOUR_API_KEY as a body parameter in every API request. The key is case-sensitive and must match exactly. There is no Bearer token, OAuth flow, or session-based authentication for the API. Failed authentication returns the JSON error: {"error":"Incorrect API key"}.

curl -X POST https://tapprsmm.com/api/v2   -H "Content-Type: application/x-www-form-urlencoded"   -d "key=YOUR_API_KEY&action=balance"

3. Endpoint Actions Reference Table

The API distinguishes operations using the action parameter in the request body. Supported actions:

• action=services — Retrieves the full active service catalog. Returns a JSON array of service objects including id, name, type, rate, min, max, refill, and cancel fields.
• action=add — Places a new order. Required parameters: service (integer service ID from the catalog), link (public URL of the target profile or post), quantity (integer within service min/max limits). Optional parameters: runs and interval for drip-feed orders. Returns: {"order":123456} on success.
• action=status — Returns the current status of a single order. Required parameter: order (integer order ID). Returns status, charge, start_count, remains, and currency fields.
• action=orders — Bulk status query for up to 100 orders in one request. Required parameter: orders (comma-separated list of integer order IDs, maximum 100). Returns a JSON object keyed by order ID, each containing the same fields as a single status query.
• action=refill — Requests a warranty refill for an eligible completed order. Required parameter: order (integer order ID). Returns {"refill":"123"} (refill ID) on success or an error object if the order is ineligible.
• action=balance — Returns the current wallet balance. Returns {"balance":"25.84","currency":"USD"} on success.

4. Order Status Definitions

Status queries return one of the following status values. Understanding each status is essential for building correct order processing logic:

• Pending — Order has been received and queued for processing. No delivery has started yet.
• Processing — The system is preparing the order for dispatch. This status typically appears briefly before In Progress.
• In Progress — Delivery is actively underway. The remains field indicates remaining quantity to be delivered.
• Completed — Full ordered quantity has been delivered successfully.
• Partial — Delivery stopped before completing the full quantity. The system returned the undelivered portion pro-rata to the wallet. This is a terminal status — no further delivery will occur.
• Cancelled — Order was rejected before delivery began. The full charged amount was returned to the wallet. This is a terminal status.

5. Placing an Order — Code Examples

Example: Place an order for 1,000 Instagram followers (service ID 102) on a public profile.

curl -X POST https://tapprsmm.com/api/v2   -d "key=YOUR_API_KEY"   -d "action=add"   -d "service=102"   -d "link=https://www.instagram.com/yourprofile/"   -d "quantity=1000"

# Success response:
# {"order":789012}

# Error response example:
# {"error":"Incorrect service ID"}

Example: Python implementation using the requests library.

import requests

API_URL = "https://tapprsmm.com/api/v2"
API_KEY = "YOUR_API_KEY"

def place_order(service_id, link, quantity):
    payload = {
        "key": API_KEY,
        "action": "add",
        "service": service_id,
        "link": link,
        "quantity": quantity
    }
    response = requests.post(API_URL, data=payload)
    result = response.json()
    if "error" in result:
        raise Exception(f"API error: {result['error']}")
    return result["order"]  # Returns order ID integer

def check_status(order_id):
    payload = {"key": API_KEY, "action": "status", "order": order_id}
    response = requests.post(API_URL, data=payload)
    return response.json()

# Usage
try:
    order_id = place_order(102, "https://www.instagram.com/yourprofile/", 1000)
    print(f"Order placed: {order_id}")
except Exception as e:
    print(f"Order failed: {e}")

6. Checking Order Status — Bulk Query

# Check up to 100 orders in one request
curl -X POST https://tapprsmm.com/api/v2   -d "key=YOUR_API_KEY"   -d "action=orders"   -d "orders=789012,789013,789014"

# Response:
# {
#   "789012": {"charge":"0.27","start_count":"1523","status":"Completed","remains":"0","currency":"USD"},
#   "789013": {"charge":"0.15","start_count":"890","status":"In Progress","remains":"200","currency":"USD"},
#   "789014": {"charge":"0.10","start_count":"650","status":"Partial","remains":"0","currency":"USD"}
# }

7. API Error Code Matrix

All API errors are returned as JSON objects with a single "error" key. Implement string matching on the error value in your backend integration:

• {"error":"Incorrect API key"} — Key is missing, malformed, or inactive. Check the key value in your request body.
• {"error":"Incorrect service ID"} — The service integer ID does not match any active catalog entry. Refresh your services list using action=services.
• {"error":"Insufficient funds"} — Wallet balance is lower than the calculated order cost. Prompt the user to deposit more funds.
• {"error":"Invalid link"} — The link parameter format is not accepted by the specified service. Verify the URL format matches the service's required format (e.g., public profile URL vs. post URL).
• {"error":"Quantity must be between X and Y"} — The requested quantity falls outside the service's minimum or maximum limits. Validate quantity against the service catalog before submission.
• {"error":"Order not found"} — The specified order ID does not exist or does not belong to this API key.
• {"error":"Refill is not available for this order"} — The order is not eligible for a warranty refill (not completed, outside the warranty window, or service has no refill warranty).

8. Webhook Configuration for Real-Time Status Updates

Order-status webhooks are available via TapprSMM's separate backend infrastructure. Webhooks send HTTP POST notifications to your configured callback URL when order status transitions occur (e.g., Pending → In Progress, In Progress → Completed, Completed → Partial). Contact TapprSMM support to configure your webhook endpoint URL and verify delivery format.

For integrations that do not require real-time status updates, polling the action=status or action=orders endpoint at 5-to-10-minute intervals is a reliable alternative. Polling intervals below 1 minute should be avoided to prevent excessive API request volumes.

9. Rate Limits and Best Practices

No hard rate limits apply to verified reseller API keys. However, the following practices are recommended to maintain reliable integration performance: Avoid polling status endpoints more frequently than once per 5 minutes for active orders. Use the bulk action=orders endpoint to check up to 100 orders per request instead of making individual action=status calls. Implement exponential backoff retry logic for transient network errors. Log all API request and response pairs for debugging and audit purposes.

10. Testing Your Integration

There is no dedicated sandbox environment. Test integrations against the live API using low-cost service packages (e.g., $0.01 view packages). Place a minimal order, verify the returned order ID, poll status until Completed or Partial, confirm the wallet deduction matches the expected charge, and verify that the target metric changed as expected. Document these test results before deploying automated production integrations.