SMM API Guide: Connecting and Tracking Orders

SMMEGY uses POST https://smmegy.com/api/v2 for server-side service and order operations. Requests can use JSON or form-data, and responses use JSON. Do not prefix the API endpoint with /ar or /en. Keep the endpoint reference open alongside this tutorial for the detailed service field definitions.

Begin with read operations. Consider a bounded order only after understanding its terms and establishing that the service method is permitted on the target platform. Automating a request does not change platform rules. The SMM panel guide, service catalog and a relevant hub such as Instagram explain the context before you connect it to your application.

Create and protect a server-side key

Key issuance requires a customer account with verified email. Use API key management, select the necessary permissions and an expiry period, and copy the complete key when it is shown once. Store it in a server environment variable or secret store. Keep it out of browser JavaScript, URLs and source repositories.

Permissions and rotation

Start with services if you only need catalog access, then add permissions your workflow requires. For routine rotation, create a replacement, update your server configuration and verify a read request before revoking the previous key. Revoke an exposed key and update the integration. Redact both the key and the Authorization header from logs.

POST /api/v2
Authorization: Bearer YOUR_SERVER_SIDE_API_KEY
Content-Type: application/json

YOUR_SERVER_SIDE_API_KEY is a placeholder. Obtain its value from your server's secret storage rather than publishing it in an example.

Supported actions and scopes

action	Main input	Required scope
services	Optional cursor, limit	services
balance	No additional fields	balance
add	service, idempotency_key, service form fields; optional coupon	orders:write
status	order or orders	orders:read
refill	order, idempotency_key	orders:actions
cancel	order, idempotency_key	orders:actions
refill_status	order	orders:actions

balance returns available funds and currency. A quote action is not part of this interface; do not infer an endpoint from terminology used elsewhere in the application.

Fetch the catalog before building an order

Start with a request such as:

{"action":"services","cursor":0,"limit":100}

The response is a service array containing identifiers, type, rate, currency, quantity limits and order_form. The allowed limit is 1–1,000. For the next page, use the last returned service identifier as cursor; stop when the list is empty. Do not assume rates or service details remain unchanged between reads.

Check order_form.supported and order_form.orderable. If ordering is blocked, inspect blocked_reason. Build your form from fields, including required, required_when, choices, min and max. Send the resulting fields directly in the add body, rather than nesting them under options.

Service type controls the inputs and quantity

Service type	Main fields or behavior
Default	link, quantity, within the service limits
Package	link; omit quantity; full package price
Custom Comments / Custom Comments Package	link, newline-separated comments; line-derived quantity or package pricing
Comment Replies / Comment Likes	username and target; comments for replies, quantity for likes
Mentions Custom List	link, newline-separated usernames; quantity comes from the list
Other mention types	The form's applicable username, usernames, hashtag, hashtags or media fields
Invites from Groups / Poll / SEO	Additional groups, answer_number or keywords, according to type
Web Traffic	country, device, type_of_traffic; conditional source fields
Subscriptions	username, min, max, posts, delay; optional old_posts, expiry

This table summarizes form behavior; it does not authorize methods that violate platform rules. Consult the full reference for each type. rate_basis=per_1000 means a price per thousand, while package means the complete package price. With drip=true, the service supports runs and an interval in minutes; billable quantity becomes quantity × runs.

Post-tracking subscriptions are finite. posts must be 1–365 and posts + old_posts cannot exceed 365. The quantity budget uses max × (posts + old_posts). A reserved budget is not a delivered quantity. Use the returned delay choices instead of inventing an interval.

Submit an order with a stable operation reference

The example below shows a Default service request. The service identifier, target and quantity are illustrative. Replace them with an orderable service, an authorized target and values within the current limits. The example does not identify a particular catalog service.

curl --request POST 'https://smmegy.com/api/v2' \
  --header "Authorization: Bearer ${SMMEGY_API_KEY}" \
  --header 'Content-Type: application/json' \
  --data '{"action":"add","service":123,"link":"https://www.instagram.com/p/REPLACE_WITH_OWNED_POST/","quantity":100,"idempotency_key":"demo-order-2026-0001"}'

SMMEGY_API_KEY is a server environment variable. Do not replace it with a key in published text. Assign one unique reference to each intended order operation. For add, idempotency_key accepts 8–128 Latin letters, digits and the characters ._:-.

After a timeout, retry the same reference and payload to retrieve the same order if it was created. Changing the payload while reusing the reference is rejected. Generating a fresh reference for every transport retry can create a separate order. Persist the operation reference and original data so your application can reconcile them after a restart.

Track creation separately from fulfillment

add returns order, public_id, charge and currency. Creation puts the order in queued and reserves funds. A successful response is not fulfillment evidence. active follows acceptance for execution, while completed records order completion. Do not display “Delivered” just because you received an identifier.

Poll an actual order with {"action":"status","order":12345}. For a batch, send orders as a comma-separated string containing up to 100 identifiers. Responses include status, charge, currency, remains, reserved, refunded and settlement_review. Monetary values are decimal strings; preserve decimal precision rather than treating them as binary floating-point totals.

Status access is restricted to the account's orders. If a finite subscription reports settlement_review=true, follow the record rather than inferring settlement from public counters. refill and cancel depend on service capability and order state. refill_status returns up to ten recent order action records, which can include refill and cancellation. A returned action record does not establish completion of that action.

Handle errors and retries deliberately

Inspect both the HTTP status and JSON body. Some results, such as an unknown order, can return an error field with a successful HTTP status. 401 indicates an invalid key; 403 indicates insufficient scope; 422 covers an unsupported action or invalid input; 413 means the request body is too large. The body limit is 65,536 bytes even where an individual field definition permits more characters.

429 concerns quotas or authentication attempts, and 503 means the interface is temporarily unavailable. Honor Retry-After when present, and use bounded backoff with jitter. Correct permission and validation errors before retrying. Default per-key limits are 60 requests per minute and 10,000 per day, and administration can change them. A retry delay does not establish that the daily quota has reset.

Batch status requests where suitable and avoid fetching the catalog for every interface element. Store only the identifiers and information needed for tracking; do not send customer passwords or card data. For support, provide the error code and relevant identifier after removing credentials and unrelated personal information, through email or Telegram, or consult the contact page.