v3.1
September 2026Optional market-native service names
The services and catalog actions now accept an optional language code for localized service names using curated market terminology in ten supported languages. Curated market terminology preserves recognizable brands and product identifiers; admins can review or refine individual names. Explicit requests add canonical-name and actual-language metadata and safely fall back to English when a translation is missing or stale. Requests without language keep the legacy English response shape unchanged; numeric service IDs remain the stable integration key.
v3.0
August 2026v3 becomes the default API
Promoted /api/v3 as the canonical endpoint and made the familiar reseller contract a direct base-URL replacement. v3 adds optional caller-controlled idempotency, 60-second protection for identical legacy adds, the advanced catalog, numeric order and refill IDs, refund_quote, account_status, single or sequential bulk cancellation with the unchanged 15-second ordinary-order window, seven-day unresolved-order refunds, batch status and refill, and signed webhooks. API throughput now uses a lifetime-successful-spend tier and one rolling 60-second account bucket shared by every key. /api/v1 and /api/v2 are exact aliases of the same current contract.
v2.5
August 2026Advanced catalog, refund reconciliation, and cancellation
Added the paginated catalog and read-only refund_quote actions, expanded add and status metadata, a 15-second cancellation window for ordinary API orders, and a full refund for an ordinary order unresolved 7 days after original creation. API webhook events now carry a stable event id, while a deliveryId remains stable across retries of the same batch; each retry gets a new timestamp and signature. Webhook delivery remains best-effort with retries, not a durable at-least-once guarantee.
v2.4
July 202612 new media platforms in the catalog
Added services for Google, Rumble, Audiomack, Tumblr, Kwai, Clubhouse, Vimeo, Deezer, Tidal, Apple Music, Quora, and GitHub. They appear in the services action like any other service and each has a dedicated public platform page. No client changes required — new service IDs simply show up in the catalog.
v2.3
June 2026Service availability enforced on add
Unavailable services reject action=add instead of silently accepting or queuing a new order. Refresh the catalog and choose an available service before retrying.
v2.2
June 2026Optional pass-through order parameters
The add action now accepts supported service-type-specific optional fields, such as a start delay and per-type engagement options. Fields already defined by a service type keep their documented meaning.
v2.1
June 2026Drip-feed parameters on order placement
The add action accepts runs and interval together for services with dripfeed=true. Total delivery is quantity × runs and cannot exceed the service maximum. Non-drip services reject these fields.
v2.0
April 2026Public launch of the v2 API
Launched the form-encoded v2 action API with rate controls, signed best-effort webhooks with retries, and idempotent order placement. The current v1 and v2 URLs are aliases of the v3 contract and use the documented shared account limit.