The Kick viewers API

Base URL & authentication

Every endpoint lives under one base URL. Authenticate each request with your secret API key in the X-API-Key header — no OAuth, no bearer tokens, no sessions.

Base URL   https://buykickviewers.com/api/v1
Auth       X-API-Key: bckv_live_xxxxxxxxxxxxxxxxxxxxxxxx
Accept     application/json

Create and manage keys in the panel under Account → API keys. You can hold up to 5 active keys and revoke any of them at any time. The raw key is shown once at creation — store it somewhere safe. Keys spend from your normal account balance, at the same prices as the dashboard; there is no separate API wallet.

Quick start — check your balance

curl https://buykickviewers.com/api/v1/balance \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Accept: application/json"

# → { "success": true, "balance": "150.75", "currency": "USD" }

Endpoints

Paths are relative to the base URL above. Today the API sells live viewers and clip views; the other services are refused with a clear error until their delivery paths launch.

Endpoint reference — copy & paste

GET  /balance — your account balance

curl https://buykickviewers.com/api/v1/balance \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Accept: application/json"

{
  "success": true,
  "balance": "150.75",
  "currency": "USD"
}

GET  /orders — list your orders

Everything your account has ever ordered — dashboard orders and API orders live in the same list. Add ?page=2 to page through. There is no total count: you have reached the last page when a response returns fewer than 20 orders (or an empty list). speed on an order is the delivery pace it was sold at — see speed_preset under POST /orders; it is null only on orders placed before delivery speed was available.

curl "https://buykickviewers.com/api/v1/orders?page=1" \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Accept: application/json"

{
  "success": true,
  "page": 1,
  "per_page": 20,
  "orders": [
    {
      "id": "LV-1042",
      "order_id": 1042,
      "service": "live_viewers",
      "channel": "yourchannel",
            "quantity": 1000,
      "speed": { "preset": "normal", "min_s": 0.9, "max_s": 1.5 },
      "status": "Delivering",
      "status_code": "ACTIVE",
      "cost": "10.00",
      "created_at": "2026-09-15T18:24:07+00:00",
      "hours": 2
    }
  ]
}

GET  /orders/{id} — one order in full

Use the numeric order_id (1042 above, not LV-1042). You see the same live progress the dashboard shows.

curl https://buykickviewers.com/api/v1/orders/1042 \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Accept: application/json"

{
  "success": true,
  "id": "LV-1042",
  "order_id": 1042,
  "service": "live_viewers",
  "channel": "yourchannel",
    "quantity": 1000,
  "speed": { "preset": "normal", "min_s": 0.9, "max_s": 1.5 },
  "status": "Delivering",
  "status_code": "ACTIVE",
  "cost": "10.00",
  "created_at": "2026-09-15T18:24:07+00:00",
  "hours": 2,
  "status_hint": "Delivery is running. Your paid time is counting down.",
  "cancel_allowed": false
}

POST  /orders — place an order

The heart of the API. The Idempotency-Key header is required: pick any unique string (up to 255 characters) per logical order. If your network drops mid-request, send the exact same request again with the same key and you get the same order back — never a double buy.

curl -X POST https://buykickviewers.com/api/v1/orders \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Idempotency-Key: order-2026-09-15-001" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
        "service": "live_viewers",
        "channel": "yourchannel",
        "quantity": 1000,
        "hours": 2
      }'

HTTP/1.1 201 Created
{
  "success": true,
  "replayed": false,
  "order": {
    "id": "LV-1043",
    "order_id": 1043,
    "service": "live_viewers",
    "channel": "yourchannel",
        "quantity": 1000,
    "speed": { "preset": "normal", "min_s": 0.9, "max_s": 1.5 },
    "status": "Queued",
    "status_code": "NEW_ORDER",
    "cost": "10.00",
    "created_at": "2026-09-15T18:31:22+00:00",
    "hours": 2,
    "status_hint": "Your order is in the queue. You can still cancel it for a full refund.",
    "cancel_allowed": true
  }
}

Retrying the same Idempotency-Key returns the same order with "replayed": true and HTTP 200 instead of 201 — bill nothing twice. Reusing a key with different parameters (service, channel, quantity, hours) is refused with 422: one key, one order.

• service — live_viewers, clip_views today; other services answer with a clear error until they launch.
• channel — the Kick channel: a bare username or a kick.com URL. For a service delivered to a clip it is read out of the clip link instead and may be omitted.
• target — for clip_views: the full kick.com clip link (https://kick.com/streamer/clips/clip_…). The clip id is stored and echoed back as target, with target_url beside it; the channel is read from the link. A bare id, a VOD link or a non-kick.com link is refused with 422 and the reason. Not accepted for channel-targeted services.
• quantity — how many units. For live viewers: minimum 10, maximum 5,000 per order (the per-channel limit below). Priced at $5.00 per 1,000 viewers per hour, deducted from your balance. A one-time service has its own minimum and takes up to 500,000 per order.
• per-channel limit — one channel can carry 5,000 viewers at a time on your account, counted across your own live orders on that channel. Going over is a 422. The limit is per channel, not per account: every other channel has its own full allowance, so it caps how deep you can go on one stream, never how many streams you can run. An order stops counting the moment its paid hours end or it is cancelled, which frees the room straight away.
• hours — for live viewers: how long the viewers stay, pay-as-you-go (2 = two hours). One-time services don't use it.
• cost — computed server-side from the live price table, exactly like the dashboard; a total from the caller is never trusted.
• speed_preset — optional delivery pace: one of the tier keys in the table below (the same tiers the dashboard's speed picker offers, under the same names), or custom. Omit it and the order runs on the service's default tier — marked in the table — exactly as a dashboard order does, and the response echoes that tier. A tier the service does not offer, or one that cannot finish the order inside the hours you are buying, is refused with 422 and the reason.
• speed_min_s, speed_max_s — required together when speed_preset is custom: the random gap between units, in seconds, with max_s ≥ min_s. Decimals are fine (0.5 is half a second). The fastest custom pace is one unit every 0.1 seconds; the slowest is 3,600 seconds, and a max_s above that is clamped down rather than refused. A custom pace is under the same rule as the tiers: it has to finish the order inside the hours you are buying. For any other preset the two fields are ignored — the range is the tier's.
• speed (response) — the pace the order was actually sold at, echoed on every order payload: the tier key and the gap it resolved to at sale time, e.g. { "preset": "normal", "min_s": 0.9, "max_s": 1.5 } (a null gap pair means the network's shared ceiling), or { "preset": "custom", … } with your own numbers. null only on orders placed before delivery speed was available. Retrying an Idempotency-Key compares the preset, and for custom the numbers too.

Delivery speeds — the tiers each service offers

Pass the key as speed_preset. Each rate is the same figure the dashboard prints for that tier; "up to" marks the network's shared ceiling, which every running order divides between them. The gap is the pause between one unit and the next, drawn at random inside the range. The default tier is what an order runs on when you send no preset.

A tier that cannot finish your order inside the hours you are buying is refused with 422: pick a faster tier or add hours. The dashboard applies the same rule.

POST  /orders/{id}/cancel — cancel an order

Only orders that have not started delivering can be cancelled — status_code NEW_ORDER (Queued) or VALIDATING (Checking your channel, or your clip) — and the full amount goes straight back to your balance. Cancelling a running order is refused with 409.

curl -X POST https://buykickviewers.com/api/v1/orders/1043/cancel \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Accept: application/json"

{
  "success": true,
  "id": "LV-1043",
  "order_id": 1043,
  "service": "live_viewers",
  "channel": "yourchannel",
    "quantity": 1000,
  "speed": { "preset": "normal", "min_s": 0.9, "max_s": 1.5 },
  "status": "Cancelled",
  "status_code": "CANCELED",
  "cost": "10.00",
  "created_at": "2026-09-15T18:31:22+00:00",
  "hours": 2,
  "status_hint": "Cancelled. Anything you did not use was returned to your balance.",
  "cancel_allowed": false
}

GET  /key/info — this key's caps and status

curl https://buykickviewers.com/api/v1/key/info \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Accept: application/json"

{
  "success": true,
  "name": "My reseller bot",
  "prefix": "bckv_live_f4a2",
  "daily_limit": "100.00",
  "monthly_limit": null,
  "per_order_limit": null,
  "expires_at": null,
  "created_at": "2026-09-15T16:02:11+00:00",
  "is_active": true
}

null means "no cap set" — the key is then only bounded by your account balance.

GET  /key/usage — spend totals and recent events

curl https://buykickviewers.com/api/v1/key/usage \
  -H "X-API-Key: bckv_live_your_key_here" \
  -H "Accept: application/json"

{
  "success": true,
  "daily_spent": "20.00",
  "monthly_spent": "84.50",
  "total_orders_created": 9,
  "total_amount_spent": "152.75",
  "last_used_at": "2026-09-15T18:31:22+00:00",
  "recent_events": [
    { "event": "order.created", "reason": "order 1043", "at": "2026-09-15T18:31:22+00:00" },
    { "event": "order.replayed", "reason": "order 1042", "at": "2026-09-15T18:26:40+00:00" }
  ]
}

Rate limits & spending caps

Errors

Every error is JSON with the same shape — an HTTP status that says what happened and one line that says why:

{ "success": false, "error": "The account balance is not enough for this order." }

Order statuses

Every order carries both a human status (wording may change as we polish copy) and a stable machine field status_code — switch your automation on status_code and treat status as display text. The full vocabulary: