One API for orders, wallet and the marketplace

One contract, versioned by date

Every endpoint lives under /v1 on the host of the storefront you are integrating with. Responses are JSON, money is a decimal string paired with an ISO 4217 currency, and timestamps are ISO 8601. Each response carries an X-Api-Version header with the date of the contract you are talking to, and an X-Request-Id you can quote to support. Errors always have the same body: an error object with a stable code, a human message and optional details, plus the request_id.

The OpenAPI 3.1 file describes every path, schema and error code. Import it into your HTTP client or generator and you get typed requests for the catalog, orders, wallet, listings, offers and deal handoffs.

Keys, scopes and the account they act for

A key is created by the account owner on the Reseller plan and is shown once; only a hash is stored. When you create it, you choose its scopes, an optional IP allowlist of up to 20 addresses and an optional expiry. Rotation creates a fresh key with the same scopes and revokes the old one, so you can roll credentials without downtime. Orders placed with a key are charged to the account wallet and appear in the same dashboard as manual orders, with their source marked as API.

Each key inherits the requests-per-minute limit of the account’s customer tier. The RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset headers tell you where you stand; when you exceed the limit the API returns 429 with a Retry-After header, and the right response is to wait exactly that long.

Idempotent writes and batches

Order creation is the only call that moves money, so it is protected twice. First, the Idempotency-Key header is mandatory: repeating a request with the same key returns the original order without a second charge, and reusing the key with a different body is refused with 409 IDEMPOTENCY_KEY_REUSE. Second, a duplicate-order window catches the same service, link and quantity sent again inside a short interval without a key match, returning 409 DUPLICATE_ORDER.

Batches accept up to 100 orders per call. Each item is validated and charged on its own, keyed by the batch key plus its index, and the response lists a result per item so one bad line never blocks the rest. Use POST /v1/orders/preview first when you want the exact charge and validation result without creating anything.

• Generate a UUID per logical order and persist it before sending.
• On timeouts, resend with the same key; never generate a new one for the same order.
• Treat 4xx codes as final and 5xx codes and 429 as retryable with backoff.

Webhooks you can trust

Every state change is written to an outbox in the same database transaction as the change itself, and a dispatcher delivers it to your https endpoint with three headers: Webhook-Id, Webhook-Timestamp and Webhook-Signature. The signature is an HMAC-SHA256 of the timestamp, a dot and the raw body, computed with the endpoint secret shown once at creation. Verify it in constant time, reject timestamps older than five minutes and deduplicate by Webhook-Id, because a retried event carries the same id.

Deliveries that do not receive a 2xx are retried after 1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours, 12 hours and 24 hours before being marked dead. Respond quickly and process asynchronously; a slow handler is the most common reason for duplicate processing.

Child panels through the SMM v2 endpoint

If your panel already speaks the widespread “SMM API v2” format, you can add this storefront as a supplier by pasting the /api/v2 URL and your key. The actions services, add, status, balance, refill, refill_status and cancel are supported, prices come back in your account currency and tier, and errors use the flat { "error": "message" } shape those panels expect. Idempotency is derived from the order content and the current minute, so accidental double submissions inside the same minute are collapsed.