OneProvider
Reseller API

Reseller API: how it works

How the OneProvider reseller platform works: reseller balance, reserve, client keys, codes, plans, the per-key dashboard and the money rule.

How the reseller platform works: the reseller balance, the reserve, client keys, codes, plans, and everything the cabinet does through a REST API for your own site or bot.

All models, capabilities, and prices Documentation index for AI agents: https://oneprovider.dev/docs/llms.txt Who can use the API API tokens are created by resellers with an activated reseller cabinet; access is granted by a OneProvider administrator.

How it works

A reseller tops up their own balance at the wholesale price and sells tokens to their clients as keys and codes. Everything you can do in the cabinet (the reseller tab at app.oneprovider.dev) is also available through the API, so you can build your own site, bot or checkout.

  • Reseller balance. A USD balance separate from your personal money. You top it up at the wholesale price; GET /pricing returns the price per 1 USD and the discount.
  • Client keys. Each key has a USD spend limit and an expiry. Your client uses it like any OneProvider key.
  • Codes. Batches of single-use codes you sell anywhere. An activated code becomes a key whose limit equals the code amount.
  • Plans. Your prices for clients: key amount, price, currency and expiry. Keys are issued from them through POST /orders.
  • Neutral per-key dashboard. Every key has a dashboard_url link: your client sees usage and the remaining balance without your branding or the key secret being exposed.

The money rule: reserve and debit

The reseller balance has three numbers:

text
Reseller balance (balance_usd) = your money on the platform
Reserved (reserved_usd) = unredeemed codes + remaining limits of live keys
Free (available_usd) = Reseller balance - Reserved

Money is not debited when you create something but when the client gets and spends the value. Until then it is only reserved:

  • A code batch only reserves the amount. Revoking unactivated codes releases the reserve.
  • An activated code becomes a key whose limit stays reserved.
  • Issuing a key reserves its limit; spending on the key debits the reseller balance.
  • Deleting a key or lowering its limit returns the unspent remainder to Free at once.
  • Pausing a key keeps its reserve.

Every new key, key top-up and code batch must fit into Free; otherwise the answer is 409 insufficient_balance. All three numbers come from GET /balance: balance_usd, reserved_usd, available_usd.

Wording for your own forms Show “$500 will be reserved (100 × $5)” rather than “will be charged to the balance”: the money is debited only when the code is activated and the client starts spending.

First request

  1. In the cabinet open the reseller tab, “API & integrations”, and create a token. The value is shown once.
  2. Put the token into an environment variable on your server and call /balance:
bash
export OP_PARTNER_TOKEN="rsk_..."
curl -s https://app.oneprovider.dev/partner/v1/balance \
-H "Authorization: Bearer $OP_PARTNER_TOKEN"
json
{
"balance_usd": "120.00",
"reserved_usd": "35.50",
"available_usd": "84.50"
}

The example shows only some of the response fields; money is always a string with two decimals. The full set is in the method reference and in the OpenAPI .

Topping up the reseller balance

The available payment providers and their minimums are in topup_providers of GET /balance. A payment is created with POST /balance/topups (scope billing; an Idempotency-Key header is required). You hand the returned payment link to the payer.

bash
curl -s -X POST https://app.oneprovider.dev/partner/v1/balance/topups \
-H "Authorization: Bearer $OP_PARTNER_TOKEN" \
-H "Idempotency-Key: topup-2026-10-08-001" \
-H "Content-Type: application/json" \
-d '{"balance_usd":"100.00","provider":"<id from topup_providers>"}'

The response contains order_id and pay_url (201). Payment status: GET /balance/topups/{order_id}; the credit is also announced by the balance.topped_up webhook event.

Audit log

GET /audit (scope read) returns the log of every action on your account: from the cabinet, by API tokens and by the system. Rows are immutable (there is no edit or delete route) and never contain secrets: no keys, tokens, codes or webhook secrets. The object is shown briefly: a key tail, a batch label or a plan name.

Audit parameters
ParameterDescription
period24h, 7d, 30d, 90d, all (default 30d)
actorSubstring of the actor label.
actionExact action (key.created) or a prefix (key.).
qSubstring of the object label.
limit, cursorRegular pagination.
bash
curl -s "https://app.oneprovider.dev/partner/v1/audit?period=7d&action=key.&limit=50" \
-H "Authorization: Bearer $OP_PARTNER_TOKEN"
json
{
"items": [
{
"id": "<row id>",
"at": "2026-10-08T12:00:00Z",
"actor": { "kind": "token", "label": "shop backend" },
"action": "key.created",
"object": { "type": "key", "label": "anna-main (...4f2a)" },
"money": { "reserve_delta": "25.00", "debit_delta": "0.00", "available_after": "59.50" },
"ip": "203.0.113.7",
"request_id": "req_..."
}
],
"next": null,
"actions": ["key.created", "key.topped_up"]
}

actor.kind is user, token or system. money (null when the action did not touch money) shows the signed changes of the reserve and of the debit; available_after may be null. The answer also carries the full list of actions in actions:

text
key.created key.topped_up key.limit_changed key.updated key.paused key.resumed key.rotated key.deleted
code_batch.created code_batch.revoked code.redeemed
plan.created plan.updated plan.deleted
token.created token.revoked
webhook.created webhook.deleted webhook.tested
balance.topup order.completed
customer.created customer.updated customer.blocked customer.unblocked
settings.updated account.activated

Conventions

  • Base URL: https://app.oneprovider.dev/partner/v1.
  • JSON everywhere; money is a USD string with two decimals ("12.50"); times are ISO 8601 UTC (2026-10-08T12:00:00Z).
  • Call the API from your server only: there is no CORS, and the token must never ship in a browser or mobile app.
  • Tokens, scopes, rate limit, errors, idempotency and pagination: Authorization & limits .

Next

Last updated: 2026-10-21 Found a bug? @Oneproviderhelpbot