SYSTEM INITIALIZING Loading Assets...
SmmPanelUS SmmPanelUS
English ENG Русский RU (СНГ)
Sign In Sign Up
Menu
Home Services API Media Center
About
Company Infrastructure
Contacts
English EN Russian (CIS) RU (CIS)
Sign In Sign Up
API Gateway v2.0

Integration Protocol

Public Classification: SMM Panel API Documentation.
Internal Architecture: Request routing gateway to execution infrastructure.

This is a technical specification for software integration. The system functions as an "Execution Layer," accepting standardized requests and distributing them across execution nodes. We do not provide "promotion services"; we provide a transactional exchange tool. Your task is to build the interface (Frontend) and business logic; our task is to ensure atomic command execution based on queue priority.

Integration requires strict adherence to Rate Limiting and data validation on your side. Unlike the web interface, the API does not forgive syntax errors. Any data format violation will result in request denial at the ingress filter level. This is not "marketing magic," but an engineering tool: you send a JSON payload, the system queues it, the provider executes it.

What the system does: Routes requests, enforces limits, returns statuses.
What the system does not do: Guarantee ROI, manage ad campaigns, assume liability for client business logic.
request.http
POST /api/v2
Host: smmpanelus.com
Content-Type: application/json
# Atomic transaction

Partner Authorization Required

Access to the data schema, Service IDs, and current throughput metrics is restricted for unauthorized requests. This is a perimeter security measure.
Log in to retrieve access keys and technical documentation.

Console Login Register

Routing Endpoint

Gateway URL https://smmpanelus.com/api/v2
Service list action = services
ParameterSpecification
keyYour API key
actionservices
JSON Output Structure
[
    {
        "service": 1,
        "name": "Followers",
        "type": "Default",
        "category": "First Category",
        "rate": "0.90",
        "min": "50",
        "max": "10000",
        "refill": true,
        "cancel": true
    },
    {
        "service": 2,
        "name": "Comments",
        "type": "Custom Comments",
        "category": "Second Category",
        "rate": "8",
        "min": "10",
        "max": "1500",
        "refill": false,
        "cancel": true
    }
]
Add order action = add
JSON Output Structure
{
    "order": 23501
}
Order status action = status
ParameterSpecification
keyYour API key
actionstatus
orderOrder ID
JSON Output Structure
{
    "charge": "0.27819",
    "start_count": "3572",
    "status": "Partial",
    "remains": "157",
    "currency": "USD"
}
Multiple orders status action = multi_status
ParameterSpecification
keyYour API key
actionstatus
ordersOrder IDs (separated by a comma, up to 100 IDs)
JSON Output Structure
{
    "1": {
        "charge": "0.27819",
        "start_count": "3572",
        "status": "Partial",
        "remains": "157",
        "currency": "USD"
    },
    "10": {
        "error": "Incorrect order ID"
    },
    "100": {
        "charge": "1.44219",
        "start_count": "234",
        "status": "In progress",
        "remains": "10",
        "currency": "USD"
    }
}
Create refill action = refill
ParameterSpecification
keyYour API key
actionrefill
orderOrder ID
JSON Output Structure
{
    "refill": "1"
}
Create multiple refill action = multi_refill
ParameterSpecification
keyYour API key
actionrefill
ordersOrder IDs (separated by a comma, up to 100 IDs)
JSON Output Structure
[
    {
        "order": 1,
        "refill": 1
    },
    {
        "order": 2,
        "refill": 2
    },
    {
        "order": 3,
        "refill": {
            "error": "Incorrect order ID"
        }
    }
]
Get refill status action = refill_status
ParameterSpecification
keyYour API key
actionrefill_status
refillRefill ID
JSON Output Structure
{
    "status": "Completed"
}
Get multiple refill status action = multi_refill_status
ParameterSpecification
keyYour API key
actionrefill_status
refillsRefill IDs (separated by a comma, up to 100 IDs)
JSON Output Structure
[
    {
        "refill": 1,
        "status": "Completed"
    },
    {
        "refill": 2,
        "status": "Rejected"
    },
    {
        "refill": 3,
        "status": {
            "error": "Refill not found"
        }
    }
]
Create cancel action = cancel
ParameterSpecification
keyYour API key
actioncancel
ordersOrder IDs (separated by a comma, up to 100 IDs)
JSON Output Structure
[
    {
        "order": 9,
        "cancel": {
            "error": "Incorrect order ID"
        }
    },
    {
        "order": 2,
        "cancel": 1
    }
]
User balance action = balance
ParameterSpecification
keyYour API key
actionbalance
JSON Output Structure
{
    "balance": "100.84292",
    "currency": "USD"
}

Architecture & Fault Tolerance: Developer Guide

The following describes the operational logic for infrastructure interaction. This document takes precedence over any marketing materials. We use a best-effort delivery model with execution queues. This means technical API availability does not guarantee instant order execution if the external channel is congested.

1. Exception Handling Protocol (Troubleshooting)

In a distributed system, errors are normal. Your client must handle them without crashing the entire pipeline. We return standard error codes in the error field. Use the following logic (ReAct Pattern) for automation:

Error: Incorrect request

  • Symptom: Server rejects the request instantly.
  • Cause: Data validation failed. Most often — incorrect ID format (string instead of integer) or missing mandatory link parameter.
  • Action: Log the full payload before sending. Check data types.

Error: Not enough funds

  • Symptom: Order is not created.
  • Cause: Atomic transaction cannot deduct funds. We operate strictly on prepaid terms.
  • Action: Set up a trigger for balance replenishment when reaching a critical threshold (Low Balance Alert).

Error: Service not found

  • Symptom: A Service ID that worked yesterday returns an error today.
  • Cause: Dynamic nature of the catalog. Providers disable gateways under load.
  • Action: Do not hardcode IDs. Update the service list via action=services every 24 hours.

2. Engineering Hygiene & Rate Limiting

Excessive API polling is a sign of poor architecture. If your script requests order status every 2 seconds, it will hit WAF limits.

  • Caching: Service lists and balance must be cached on your side (Redis/Memcached) with a TTL of at least 10 minutes.
  • Queues: Order statuses do not update instantly. Check them in batches every 15-20 minutes. More frequently is pointless; data won't change.
  • Asynchrony: Do not block the main execution thread waiting for an API response. Use background tasks (Celery, RabbitMQ).

3. Liability Segmentation

We provide the transport layer. We guarantee that the request will be accepted and passed to the execution network. However:

  • We do not control the algorithms of end platforms.
  • We do not validate the quality of your links (private profiles, geo-blocking are client responsibilities).
  • Execution speed depends on the current load of global gateways.

This document describes technical interaction parameters. Any financial outcomes depend on the business logic configuration on the partner's side.