Эта страница ещё не переведена на Русский. Показан английский оригинал.

GET /key and /auth/key

The state of the key you are using

Returns what the API key on the current request is: which key it is, what its limit is, and how much of it has been spent. It changes nothing — it does not create, modify or revoke anything. It is the natural call for an SDK to make at startup to check that a key is alive.

GET /key and GET /auth/key return exactly the same body. Both paths exist so that code written against openrouter works unchanged whichever one it happens to call.

GET https://openrouter.myip.co.kr/api/v1/key
GET https://openrouter.myip.co.kr/api/v1/auth/key

Authentication

Authorization: Bearer <key> is required. Both key kinds are accepted — inference keys (sk-mo-v1-…) and management keys (sk-mo-mgmt-v1-…). Forcing a key kind on the endpoint that inspects the key itself would leave you with no way to ask "is my key still valid?". The is_management_key field in the response tells you which kind you sent.

The /keys endpoints, which create and revoke other keys, are different: they take a management key only. See GET and POST /keys.

Request parameters

None. The endpoint takes no query parameters and no body. Which key is described is decided entirely by the Authorization header.

Request example

curl https://openrouter.myip.co.kr/api/v1/key \
  -H "Authorization: Bearer $MYIP_API_KEY"

Response

A single object wrapped in {"data": { … }}. Every amount is in Korean won (KRW), and the response header X-MyIP-Currency: KRW states that explicitly.

labelstring

The masked key string, in the form sk-mo-v1-au7…890 — the prefix plus three characters at each end. The plaintext key is returned once at creation and never stored, so it cannot be recovered from this.

namestring

The name given to the key when it was created.

limitnumber | null

Spend limit for this key, in won. null means unlimited.

usagenumber

Amount this key has spent during the current limit_reset period, in won. When limit_reset is null or never, this is the total since the key was created. In other words usage is always measured on the same ruler as limit.

limit_remainingnumber | null

limit - usage, floored at 0. null when limit is null.

limit_resetstring | null

One of never, daily, weekly, monthly, or null. Period boundaries are computed in Asia/Seoul.

is_free_tierboolean

Always false. There is no free tier.

is_management_keyboolean

true for a management key (sk-mo-mgmt-v1-…).

is_provisioning_keyboolean

Always the same value as is_management_key. It is openrouter's name for the same thing, kept for compatibility; we have no separate provisioning-key concept.

creator_user_idstring

UUID of the user who owns the key.

expires_atstring | null

Expiry timestamp (ISO 8601). Normally null, meaning no expiry. The only keys that carry a value are the one-hour temporary keys issued by the Chat page.

include_byok_in_limitboolean

Always false.

byok_usagenumber

Always 0, as are byok_usage_daily, byok_usage_weekly and byok_usage_monthly. We do not support BYOK (bringing your own provider key), so these fields are present for shape compatibility and filled with zero.

usage_dailynumber

Amount this key spent today, in won. usage_weekly and usage_monthly work the same way, with day, week and month boundaries taken in Asia/Seoul. All three are always returned, regardless of limit_reset.

rate_limitobject

A fixed {"requests":1000,"interval":"1h","note":"This field is deprecated and safe to ignore."}. Actual request throttling is applied in front of the gateway, not by this value — see Rate limits.

Response example

json

{
  "data": {
    "label": "sk-mo-v1-au7…890",
    "name": "production",
    "limit": 100000,
    "usage": 25500,
    "limit_remaining": 74500,
    "limit_reset": "monthly",
    "is_free_tier": false,
    "is_management_key": false,
    "is_provisioning_key": false,
    "creator_user_id": "3f1c0e9a-5f0a-4c2f-9f39-3a2e1b5c7d40",
    "expires_at": null,
    "include_byok_in_limit": false,
    "byok_usage": 0,
    "byok_usage_daily": 0,
    "byok_usage_weekly": 0,
    "byok_usage_monthly": 0,
    "usage_daily": 1200,
    "usage_weekly": 9000,
    "usage_monthly": 25500,
    "rate_limit": {
      "requests": 1000,
      "interval": "1h",
      "note": "This field is deprecated and safe to ignore."
    }
  }
}

Where the usage numbers come from

The usage family is computed from usage records, not from the credit ledger. The ledger is per user, and per-key spend does not exist in it. So if one account uses three keys, the three keys' usage values add up to total_usage from GET /credits.

Settlement happens after the response is sent, so a call that has just finished may take a moment to appear in usage.

Errors

Status	`error_type`	When
401	`invalid_api_key`	No `Authorization` header, or a malformed one. A token that does not carry one of our prefixes (`sk-mo-v1-`/`sk-mo-mgmt-v1-`). An unknown key. A key the user has switched off (`disabled`). A revoked key
401	`expired_api_key`	`expires_at` is in the past
402	`insufficient_credits`	The key is `suspended_no_credit`. `metadata.balance_krw` carries the current balance. Topping up lifts it automatically
403	`key_suspended`	An administrator suspended the key (`suspended_admin`). Topping up does not lift it
500	`server`	Any other server-side failure

The error body has the same shape on every endpoint. message is a human-readable sentence written in Korean, the service's primary locale; branch on metadata.error_type, never on the message text.