--- name: sanjaaqak-com-smm-api description: Use the customer SMM API at sanjaaqak.com to discover services, check wallet balance, place authorized orders, track delivery, and request refill or cancellation. --- # سنجاقک SMM API Use this self-contained skill for customer API tasks on sanjaaqak.com. The request and response reference below is sufficient; no separate API documentation is required. It does not provide admin access or an API for other product families. ## Connection and authorization - Endpoint: `https://sanjaaqak.com/api/smm/v1`. - The customer creates their key at [API settings](https://sanjaaqak.com/profile/api). - Send HTTPS POST with `Content-Type: application/json` and a JSON body containing `key` and `action`. Form-encoded POST is also accepted. Prefer POST over GET so keys do not enter URL history or access logs. - Obtain the key through the customer's configured secret store or environment. Never print it, commit it, put it in a URL, or send it to another host. Redact request bodies in logs. - Keep the endpoint, key, catalog, wallet, and order IDs on this brand. A key or ID from another domain is not interchangeable. - Reading this skill does not authorize spending. Before `add`, establish the target, service, quantity, estimated charge, and customer-approved budget. Existing explicit authorization within those bounds is sufficient; ask only for missing decisions. - Use only the documented customer endpoint. Do not use browser session cookies, internal server actions, admin routes, or upstream provider APIs. ## API request reference Every action uses the same endpoint: `https://sanjaaqak.com/api/smm/v1`. Do not invent `/services`, `/orders`, or per-action URLs. The API accepts GET and POST; use POST for both reads and mutations. Every JSON body includes `key` (the API key, not a Bearer token) and `action`. Responses have `Content-Type: application/json`. | action | Additional request fields | Successful response | | --- | --- | --- | | `services` | None | Service array | | `balance` | None | `{ "balance": "15000.00", "currency": "IRT" }` | | `add` | Numeric `service`; fields for the service type below | `{ "order": "ord_xxx" }` | | `status` | One `order`, or comma-separated `orders` | One status object, or an object keyed by order ID | | `refill` | One `order`, or comma-separated `orders` | `{ "refill": "sact_xxx" }`, or an array of per-order results | | `refill_status` | One `refill`, or comma-separated `refills` | `{ "status": "In progress" }`, or an array of per-refill results | | `cancel` | One `order`, or comma-separated `orders` | `{ "cancel": 1 }`, or an array of per-order results | Use either the singular or plural ID field, not both. Batch requests accept at most 100 IDs; split larger read batches into groups of 100. `service` is a positive integer; quantities are positive integers, and post counts are integers subject to the advertised limits. API keys, order IDs, and refill IDs are strings. Never convert `ord_...` or `sact_...` to numbers. ## Read the current catalog and wallet POST these bodies separately, supplying the key securely: ```json {"key":"YOUR_KEY","action":"services"} ``` ```json {"key":"YOUR_KEY","action":"balance"} ``` `services` returns an array of up to 2,000 orderable services, not an `ok` envelope. Important fields: - `service`: numeric ID required by `add`. Do not send the string `service_id` or an upstream provider ID. - `name`, optional `name_en`, `platform`, `category`, and `category_arr`: match the customer's intent. - `type`: `Default`, `Custom Comments`, or `Subscriptions`. - `rate`: IRT (Iranian toman) per 1,000 units. `min` and `max` bound the quantity. - `refill` and `cancel`: standard-service capabilities; they do not guarantee that a particular order is eligible. - Optional `score`, `average_time`, `average_time_per_1k`, and `drop_rate` are selection signals, not delivery guarantees. Times are minutes. - `dripfeed` is false; do not invent drip-feed options. Balance is returned as `{"balance":"15000.00","currency":"IRT"}`. IRT is toman, not IRR (rial). All API orders use the wallet; insufficient funds require customer action. Example `services` response (IDs, prices, and names are illustrative): ```json [ { "service": 123, "service_id": "svc_example", "name": "Example service", "type": "Default", "rate": 1500, "min": 100, "max": 10000, "dripfeed": false, "refill": true, "cancel": true, "category": "Telegram > Members", "category_arr": ["telegram", "members"], "platform": "telegram", "currency": "IRT" } ] ``` Read current rates and limits before ordering. Do not assume a missing service can be ordered or invent service IDs, prices, supported platforms, or guarantees. ## Place an order For a `Default` service: ```json { "key": "YOUR_KEY", "action": "add", "service": 123, "link": "https://t.me/example", "quantity": 1000 } ``` The service ID and target are examples: use the customer's target and a numeric ID from the current catalog. Validate quantity against the selected service's limits. A link may have additional service-specific requirements; surface validation errors rather than guessing a replacement target. Estimated standard charge: `ceil(quantity * rate / 1000)` whole toman. Check available balance and the approved budget. Submission deducts the wallet immediately and returns `{"order":"ord_xxx"}`; this acknowledges creation, not completed delivery. Save the returned ID before further work. ### Custom Comments For `Custom Comments`, send `link` and `comments` (one comment per line), and omit `quantity`: ```json { "key": "YOUR_KEY", "action": "add", "service": 27, "link": "https://instagram.com/p/example", "comments": "First comment\nRepeated comment\nRepeated comment" } ``` Quantity is the number of non-empty lines after normalization. Duplicates count separately. Check that count against `min`/`max`; charge uses the standard formula. Preserve customer-approved comment text. ### Subscriptions For `Subscriptions`, send `username` instead of `link`, plus `quantity` per execution and supported post counts: ```json { "key": "YOUR_KEY", "action": "add", "service": 14186, "username": "example", "quantity": 100, "posts": 10, "old_posts": 5 } ``` Use `posts` only if `new_posts_min`/`new_posts_max` are present, and `old_posts` only if `old_posts_min`/`old_posts_max` are present. Each enabled post type must satisfy its own bounds. Omit disabled post types. The example requires a service supporting both. The full upfront charge is `ceil(quantity * rate / 1000) * (posts + old_posts)`, with omitted counts treated as zero. Do not round only after multiplying by post counts. Delay is always zero; expiry is unsupported. Do not import parameters from other SMM panels. ## Track orders ```json {"key":"YOUR_KEY","action":"status","order":"ord_xxx"} ``` Example standard `status` response: ```json { "charge": "1500.00", "start_count": null, "status": "Pending", "remains": null, "currency": "IRT" } ``` A standard order returns `charge` (decimal string), `start_count` (string or null), `status`, `remains` (string or null), and `currency: "IRT"`. Unknown counts are not zero. For up to 100 known orders, send `orders` as a comma-separated string instead of `order`: ```json {"key":"YOUR_KEY","action":"status","orders":"ord_xxx,ord_yyy"} ``` The response is an object keyed by order ID, such as `{"ord_xxx":{"charge":"1500.00","start_count":null,"status":"Pending","remains":null,"currency":"IRT"},"ord_yyy":{"error":"Incorrect order ID"}}`. Inspect each entry for `error`. Statuses include `Pending`, `Processing`, `In progress`, `Active`, `Completed`, `Partial`, `Canceled`, `Error`, `In review`, and `Awaiting Payment`. Report the returned state; do not infer successful delivery from successful submission. An `Error` or `In review` is not permission to create a replacement order. Subscriptions return `status`, `expiry: null`, `posts` (string), `old_posts` (number), `orders`, and `old_orders`. Child IDs are provider-returned IDs; do not assume they are customer API order IDs. Use bounded polling when requested; an interval such as 60 seconds is a client choice, not a documented API rate limit. Stop on the requested outcome, an error requiring customer action, or the agreed monitoring deadline. Do not run an unbounded loop. ## Refill and cancellation Perform these mutations only when requested or covered by the customer's existing instructions. Refill request: ```json {"key":"YOUR_KEY","action":"refill","order":"ord_xxx"} ``` Success: `{"refill":"sact_xxx"}`. Save this local refill-request ID. Refill-status request: ```json {"key":"YOUR_KEY","action":"refill_status","refill":"sact_xxx"} ``` Success: `{"status":"In progress"}`. Other states are `Pending`, `Completed`, `Rejected`, `Failed`, and `In review`. Cancellation request: ```json {"key":"YOUR_KEY","action":"cancel","order":"ord_xxx"} ``` Success: `{"cancel":1}` means accepted. Acceptance does not confirm cancellation or an immediate refund; check order status. Standard refills require `refill: true`, a provider-submitted order in `Completed` or `Partial`, at least 24 hours since submission, at least 24 hours after the previous refill finished, and no active refill. Standard cancellations require `cancel: true`, provider submission, and a non-final order state. The API is authoritative about eligibility. Subscriptions always advertise `cancel: false`; subscription cancellation can still be separately available with account/time limits. For an authorized subscription cancellation, use the same `cancel` request above with the parent order ID. The server checks service/provider configuration, the allowed cancellation window, and per-account request limits. Report any rejection; never promise availability or a refund. Batch refill/cancel accepts `orders`; batch refill status accepts `refills`. Each is a comma-separated string of at most 100 IDs. Batch replies are arrays: - Refill: `[{"order":"ord_xxx","refill":"sact_xxx"}]`. - Cancel: `[{"order":"ord_xxx","cancel":1}]`. - Refill status: `[{"refill":"sact_xxx","status":"Completed"}]`. A failed item's `refill`, `cancel`, or `status` value can instead be `{"error":"..."}`. Inspect every item; do not treat HTTP success as batch success. ## Errors and uncertain outcomes Responses use the shapes above, without `ok` or `data` wrappers. Validate both HTTP status and parsed JSON, including top-level and per-item errors. A missing/wrong order can return `{"error":"Incorrect order ID"}` with HTTP 200; a missing refill can return `{"error":"Refill not found"}` with HTTP 200. - `Invalid API key` / HTTP 401: ask the customer to check the current-brand credential securely; never echo it. - `Insufficient Funds`: explain the required amount and wallet shortage. Do not initiate a top-up. - Invalid quantity, target, service, or post counts: use the current catalog and request fields above to correct only the customer's intended request. - `Order not allowed for this account` / HTTP 403: the account cannot place orders; ask the customer to contact support. - Refill/cancel rejections such as `provider_action_unavailable`, `refill_not_enabled`, `cancel_not_enabled`, `refill_not_available_for_status`, or `cancel_not_available_for_status`: the requested operation is not available for this order; do not repeatedly resubmit. - `action_already_pending`: an action is already active. Track a known refill ID or order status instead of sending another request. - `refill_available_24_hours_after_order_submission` or `refill_available_24_hours_after_last_action`: explain the waiting period; do not retry before it elapses. - Network timeout, disconnected response, invalid JSON, or server error during `add`: creation may already have happened. This API exposes no idempotency key or order-search/list action. Do not automatically retry `add`. If an ID was received, check it with `status`; otherwise ask the customer to reconcile their [orders](https://sanjaaqak.com/profile/orders) or contact support before resubmission. - For an uncertain refill/cancel result, check the known refill/order state before considering another mutation. - A failed read can be retried with a small bounded backoff. Do not repeat mutations merely because reads fail. Summarize the selected service, estimated/returned charge in toman, order/refill ID, current status, and any required customer action. Never claim that an operation was executed when you only prepared a request.