API documentation

Send key and action in an application/x-www-form-urlencoded body; JSON is also accepted. URL query parameters and query keys are rejected. Production requires HTTPS. GET is unsupported. Examples use placeholders only.

curl -X POST 'https://smmvelox.com/api/v2' \
  --data-urlencode 'key=YOUR_API_KEY' \
  --data-urlencode 'action=add' \
  --data-urlencode 'service=123' \
  --data-urlencode 'link=https://example.com/post' \
  --data-urlencode 'quantity=1000' \
  --data-urlencode 'client_order_id=YOUR_UNIQUE_ORDER_ID' \
  --data-urlencode 'max_charge=11550'

API key authentication

Keep keys secret and send them only in the body. Never put keys in URLs or frontend code, or share them. Rotation/revocation invalidates the old key immediately. Accounts must be active and email verified.

Send the API key over HTTPS in the POST body only. Never put a key in a URL or browser-side code.

API prices and settlement always use VND. UI USD amounts are reference displays only.

V1 exposes verified Default services only: rate is VND per 1,000 units, charge = rate × quantity / 1,000. Service is the internal DV-ID; order is a stable local ID string. No upstream IDs. Money uses exact decimal strings with up to 12 fractional digits.

key=YOUR_API_KEY&action=services

[
  {
    "service": 123,
    "name": "Example",
    "desc": "",
    "type": "Default",
    "category": "Facebook",
    "platform": "facebook",
    "rate": "11550.000000000000",
    "rate_unit": "per_1000",
    "min": "100",
    "max": "100000",
    "refill": false,
    "cancel": false,
    "dripfeed": false,
    "currency": "VND"
  }
]

API prices and settlement always use VND. UI USD amounts are reference displays only.

key=YOUR_API_KEY&action=balance

{
  "balance": "100000.000000000001",
  "currency": "VND"
}

add requires a positive integer service, an http/https link up to 2,000 characters, and integer quantity within min/max. price/rate/discount/currency/user_id/status/provider and unknown fields are rejected. Batch status accepts at most 100 IDs.

key=YOUR_API_KEY&action=add&service=123&link=https://example.com/post&quantity=1000&client_order_id=YOUR_UNIQUE_ORDER_ID

{
  "order": "456"
}

Status may be Pending, Processing, In progress, Completed, Partial or Canceled based on verified evidence. Unknown/review orders return Pending with review_required=true. start_count/remains are null without evidence, never invented zeros. charge always uses the paid snapshot.

key=YOUR_API_KEY&action=status&order=456

{
  "charge": "11550",
  "status": "Pending",
  "start_count": null,
  "remains": null,
  "currency": "VND",
  "review_required": false
}

Responses are objects keyed by order ID. Missing IDs receive individual errors. Up to 100 IDs per call.

key=YOUR_API_KEY&action=status&orders=456,999

{
  "456": {
    "charge": "11550",
    "status": "Pending",
    "start_count": null,
    "remains": null,
    "currency": "VND",
    "review_required": false
  },
  "999": {
    "error": "Incorrect order ID"
  }
}

Package/per_unit, custom comments, subscriptions and dripfeed are unsupported and hidden. cancel, refill and refill_status return HTTP 400 Action is not supported; no status mutation or automatic refund. V1 cancel/refill/dripfeed flags are always false.

key=YOUR_API_KEY&action=cancel

{
  "error": "Action is not supported"
}

Ordering and status rules

A connection can fail after an order has already been accepted and charged. A timeout or HTTP 503 does not prove the request was not processed. Assign a unique reference to every intended order.

1. Before the first add request, generate a unique client_order_id (or idempotency_key). Store it alongside the submitted service, link, quantity and max_charge.
2. When an order ID is returned, save it and check with action=status and order. Do not create another add request merely to check status.
3. If the response times out or disappears and there is no order ID, retry only when the connection and API are available. Send the exact same action=add, reference and original parameters. Never generate a new reference for that attempt.
4. If a retry returns an order ID, track that ID. Otherwise, stop repeated automatic retries and contact support with the request reference (never your API key).

curl -X POST 'https://smmvelox.com/api/v2' \
  --data-urlencode 'key=YOUR_API_KEY' \
  --data-urlencode 'action=add' \
  --data-urlencode 'service=123' \
  --data-urlencode 'link=https://example.com/post' \
  --data-urlencode 'quantity=1000' \
  --data-urlencode 'client_order_id=YOUR_UNIQUE_ORDER_ID' \
  --data-urlencode 'max_charge=11550'

Status lookup does not accept client_order_id; action=status requires the returned order ID. Without an order ID, safely repeat the identical add request when the API is ready or contact support.

Example JSON errors and recovery steps

{
  "error": "Client order ID conflicts with an existing request"
}

{
  "error": "Invalid request parameters",
  "fields": [
    "quantity"
  ]
}

{
  "error": "Rate limit exceeded"
}

{
  "error": "API order creation is disabled"
}

The JSON bodies illustrate actual error shapes; error wording can vary with the cause. Handle the HTTP status and underlying condition.

HTTP status codes

Errors are JSON objects with an error field; authentication and internal details are not disclosed.

Security, limits and errors

Optional: up to 20 exact IPv4/IPv6 addresses, one per line. Empty means no IP restriction. CIDR is unsupported. Invalid lists are rejected without changing existing restrictions.

Per minute: 60 requests/IP before authentication; additionally 120 reads or 15 adds per user and key. Maximum body 64 KiB. 429 includes Retry-After. Client-supplied Forwarded/X-Forwarded-For is not trusted.

FAQ: Get keys after signing in. Lost keys must be rotated; old secrets cannot be displayed again. Provider keys do not work here. V1 (2026-10-30): services, balance, Default add and single/batch status. After-sales actions remain V2 work pending safe workflows.