KA BOT API

Start here

Connect your bot to KA BOT and redeem PUBG UC over HTTP. Get one successful test call before you wire customer checkout.

Base URL: https://api.kabotapi.com · every response carries KA-Version and X-Request-Id.

Authentication

Authorization: Bearer pk_0123456789abcdef0123456789abcdef

X-API-Key: pk_… is accepted as an alternative. Live keys are pk_ + 32 hex chars (35 chars total). Test keys use prefix sk_test_ (same length pattern). Keys are issued per merchant in Telegram (/api_system → Generate key, shown once). An API plan is assigned by the operator — there is no self-serve catalog. Message @Nogitsuneiii to get or change a plan.

Server-side only. Your key can spend your codes and your wallet. Never put it in a browser page, a mobile app, or a query string — call the API from your backend and keep the key in an environment variable.
sk_test_ is not a sandbox. Test-prefix keys still redeem real codes and debit real quota. Use a disposable stock wallet for integration tests.

Scopes

ScopeGrants
redeemPOST /v1/redeem
read/v1/me, /v1/stock, /v1/jobs/*, POST /v1/webhook

Keys can also be IP-restricted. Several keys may be active at once, so rotation needs no downtime: create the new key, deploy it, then revoke the old one.

API plan, and when a bot subscription is required

Every call needs an active API plan (plan_active: true on GET /v1/me). A Telegram bot subscription is required only when subscription.required is true. If the bot is free, required is false, active is always true, and 402 subscription_expired is never returned.

GET /v1/me is the source of truth:

"subscription": { "active": true, "required": false, "expires_at": null, "days_left": null }

When required is true, poll daily and warn your team on days_left <= 3. When it is false, ignore days_left — there is nothing to renew.

First successful request

  1. Key — /api_system in Telegram.
  2. Smoke test — GET /v1/me (plan, quota, balance, subscription) or GET /v1/stock (inventory).
  3. Redeem — POST /v1/redeem with exactly one code source and an Idempotency-Key header.
  4. Read the result — each code comes back with a status and a disposition.
  5. Long jobs — send "async": true, then poll GET /v1/jobs/{job_id} or take a webhook.
If /v1/me fails, fix the key / plan first (and the bot subscription only if subscription.required is true) — do not debug redeem yet. 
curl -sS "{{BASE}}/v1/me" \
  -H "Authorization: Bearer pk_0123456789abcdef0123456789abcdef"

Pick a code source

A · Your database

You already hold codes in your bot DB. Send them in codes. We hold no copy, so every result comes back as disposition: "unchanged".

B · KA BOT inventory

Codes sit in your KA BOT stock (/addcodes or buy). Send uc, categories, or packs. We report per code whether it was consumed, deleted, or returned to stock.

One source per request. Mixing codes with inventory fields → 400 ambiguous_source. Details and failure handling → Redeem.

Billing (short)

You pay for outcomes, not attempts. Requests are charged up front, then every code whose failure was caused by our infrastructure is refunded automatically and reported as refunded_requests.

Free: GET /v1/health, GET /v1/me, GET /v1/stock, GET /v1/jobs/{id}, POST /v1/webhook. Full rules → Limits.

Chat redeem inside KA BOT (active subscription) does not use API quota. Checker is priced separately.

Next Redeem →