GET and POST /keys

Lists the inference keys an account holds (GET) and issues new ones (POST). Both methods require a management key.

GET  https://openrouter.myip.co.kr/api/v1/keys
POST https://openrouter.myip.co.kr/api/v1/keys

Authentication — the most common mistake

Authorization: Bearer sk-mo-mgmt-v1-…, that is, a management key only. Calling with an inference key (sk-mo-v1-…) returns 401 invalid_api_key.

The two kinds do different jobs.

Management keys cannot be created over the API. You issue one yourself in the dashboard under Settings → API keys by choosing the management kind. Letting a management key mint further management keys would mean a single leaked key has no recovery point.

GET /keys — list

Request parameters

None. The endpoint takes no query parameters.

openrouter's offset and include_disabled are not implemented. Our list returns all of the management key owner's inference keys in one response, newest first. Two things are never in it:

• Revoked keys. They cannot be brought back, so there is nothing to show.
• The management key itself. Only issued inference keys appear.

Keys the user has merely switched off (disabled: true), and keys stopped by an empty balance or by an administrator, all remain in the list and all show disabled: true.

Request example

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

Response

{"data": [ … ]}, where each item is a key object with eight fields. POST /keys, GET /keys/{hash} and PATCH /keys/{hash} all return this same object.

Response example

{
  "data": [
    {
      "created_at": "2026-09-01T02:11:40.881Z",
      "updated_at": null,
      "hash": "9f2c1d0a7b3e4f5061728394a5b6c7d8e9f0112233445566778899aabbccddee",
      "label": "sk-mo-v1-au7…890",
      "name": "production",
      "disabled": false,
      "limit": 100000,
      "usage": 25500
    },
    {
      "created_at": "2026-08-20T11:05:02.130Z",
      "updated_at": "2026-08-29T09:41:18.004Z",
      "hash": "1a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f809",
      "label": "sk-mo-v1-c3f…21b",
      "name": "staging",
      "disabled": true,
      "limit": null,
      "usage": 0
    }
  ]
}

POST /keys — issue

Creates a new inference key. There is no kind parameter, so this path cannot create management keys.

Request parameters

Request example

curl -X POST https://openrouter.myip.co.kr/api/v1/keys \
  -H "Authorization: Bearer $MYIP_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "batch-worker",
    "limit": 50000,
    "limit_reset": "monthly"
  }'

Response

{
  "data": {
    "created_at": "2026-09-04T05:22:07.412Z",
    "updated_at": null,
    "hash": "4d6a8b2c0e1f3a5b7c9d0e2f4a6b8c0d1e3f5a7b9c1d3e5f7a9b1c3d5e7f9a1b",
    "label": "sk-mo-v1-8f2…c41",
    "name": "batch-worker",
    "disabled": false,
    "limit": 50000,
    "usage": 0
  },
  "key": "sk-mo-v1-8f2b6d1e0a4c7f93b5d8e02a6c1f4b7d9e3a5c8f0b2d4e6a8c0f2b4d6e8c41"
}

hash is precisely the SHA-256 of the returned key. You can check it yourself.

printf '%s' "$PLAINTEXT_KEY" | sha256sum

Errors

{
  "error": {
    "code": 400,
    "message": "`name` 이 필요합니다.",
    "metadata": { "error_type": "invalid_request" }
  }
}

message is written in Korean, the service's primary locale. Branch on metadata.error_type, not on the message text.

The three ways an issued key stops working

Separately, if a key has a limit and its period spend has reached it, requests get 402 key_limit_exceeded, with metadata.limit_krw and metadata.usage_krw attached.

Related

• GET, PATCH and DELETE /keys/{hash} — read, update and revoke one key
• GET /key and /auth/key — the state of the key you are using
• Management API keys — when to use a management key
• Errors and debugging — the full error_type table