Read actions and risky write actions must be separated in SMM panel integrations. This guide explains permissions, approval queues, and safe AI actions.

Overview

API scope can vary across PerfectPanel-compatible SMM providers. Yanitly therefore defaults to read-first behavior; creating orders, cancelling, refunding, or suspending users require explicit permission and approval.

Permission Model

Read permissions
Listing orders, services, users, payments, and support tickets is a lower-risk information retrieval workflow.

Write permissions
Creating orders, changing balances, issuing refunds, cancelling orders, or changing user status is enabled explicitly.

Tenant-scoped access
Each customer uses a separate permission set for its own panel; one tenant permission never carries into another tenant.

Code example

{
  "readOrders": true,
  "readServices": true,
  "readUsers": true,
  "createOrder": false,
  "cancelOrder": false,
  "refundPayment": false,
  "suspendUser": false,
  "requireApprovalForWriteActions": true
}

Pending Actions

When AI or an operator requests a risky action, the action is not sent directly to the provider API.
The request enters a pending actions queue and waits for approval from an authorized user.
The approval screen shows action type, target resource, expected impact, and creation time.
Expired or rejected actions are never forwarded to the provider API.

Rate Limits and Queueing

SMM providers may use different rate limits. Yanitly should respect Retry-After on 429 responses, apply exponential backoff, and process requests for the same tenant through an ordered queue.

Audit Checks

API keys are never written into conversation replies or public logs.
Every risky action should record tenant, integration, action, actor, and timestamp in the audit trail.
AI decisions should be summarized as context; money, balance, or order-changing actions must pass permission checks.
Provider documentation link and last verification date should remain visible on the integration page.