MyIP

GET /key · /auth/key

지금 쓰고 있는 키의 상태

지금 요청에 쓴 API 키가 어떤 키이고, 한도가 얼마이고, 얼마나 썼는지를 돌려준다. 키를 바꾸지도, 만들지도, 지우지도 않는다. SDK 가 시작할 때 "이 키가 살아 있는가"를 확인하는 용도로 쓰기 좋다.

GET /key 와 GET /auth/key 는 완전히 같은 응답을 준다. 두 경로를 다 여는 이유는 openrouter 를 쓰던 코드가 둘 중 어느 쪽을 부르든 그대로 동작하게 하기 위해서다.

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

인증

Authorization: Bearer <키> 가 필요하다. 추론 키(sk-mo-v1-…)와 관리 키(sk-mo-mgmt-v1-…) 둘 다 받는다. 자기 자신을 보는 경로에까지 키 종류를 강제하면 "내 키가 살아 있는가"를 확인할 방법이 없어지기 때문이다. 응답의 is_management_key 로 어느 쪽인지 알 수 있다.

다른 키를 만들거나 지우는 /keys 계열은 다르다. 그쪽은 관리 키만 받는다 — GET/POST /keys 를 보라.

요청 파라미터

없다. 쿼리 파라미터도 본문도 받지 않는다. 어떤 키를 조회할지는 Authorization 헤더가 결정한다.

요청 예시

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

응답

{"data": { … }} 로 감싼 객체 하나다. 금액은 전부 원(KRW) 이고, 응답 헤더 X-MyIP-Currency: KRW 가 그 사실을 못박는다.

labelstring

마스킹된 키 문자열. sk-mo-v1-au7…890 형태로 접두사와 앞뒤 세 글자만 보인다. 평문은 발급 시 한 번만 나가고 저장하지 않으므로 여기서 복원할 수 없다.

namestring

발급할 때 붙인 이름.

limitnumber | null

이 키의 사용 한도(원). null 이면 무제한이다.

usagenumber

limit_reset 기간 동안 이 키가 쓴 금액(원). limit_reset 이 null 이거나 never 면 발급 이후 전체 누적이다. 즉 usage 는 항상 limit 과 같은 자를 쓰는 값이다.

limit_remainingnumber | null

limit - usage, 최소 0. limit 이 null 이면 이 값도 null 이다.

limit_resetstring | null

never · daily · weekly · monthly 중 하나 또는 null. 기간 경계는 Asia/Seoul 기준이다.

is_free_tierboolean

항상 false. 무료 등급이 없다.

is_management_keyboolean

관리 키(sk-mo-mgmt-v1-…)면 true.

is_provisioning_keyboolean

is_management_key 와 같은 값이다. openrouter 가 쓰던 이름을 함께 남겨 둔 것뿐이고 우리에게 별개의 프로비저닝 키 개념은 없다.

creator_user_idstring

이 키를 소유한 사용자의 UUID.

expires_atstring | null

만료 시각(ISO 8601). 보통 null(무기한)이다. 값이 있는 키는 Chat 화면이 발급하는 1시간짜리 임시 키뿐이다.

include_byok_in_limitboolean

항상 false.

byok_usagenumber

항상 0. byok_usage_daily, byok_usage_weekly, byok_usage_monthly 도 마찬가지다. BYOK(사용자가 직접 가져온 provider 키)를 지원하지 않으므로 형상 호환을 위해 0 으로 채운다.

usage_dailynumber

오늘 이 키가 쓴 금액(원). usage_weekly, usage_monthly 도 같은 방식이며, 경계는 Asia/Seoul 의 일·주·월 시작이다. limit_reset 과 무관하게 항상 셋 다 내려온다.

rate_limitobject

{"requests":1000,"interval":"1h","note":"This field is deprecated and safe to ignore."} 고정값이다. 실제 요청 제한은 이 값이 아니라 게이트웨이 앞단에서 건다 — 요청 한도 를 보라.

응답 예시

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."
    }
  }
}

사용량은 어디서 오는가

usage 계열 값은 크레딧 원장이 아니라 사용 기록(usage_records) 에서 온다. 원장은 사용자 단위이고 키 단위 사용액은 원장에 없기 때문이다. 그래서 한 사용자가 키 세 개를 쓰면 세 키의 usage 합이 GET /credits 의 total_usage 와 맞는다.

정산은 응답을 보낸 뒤에 일어나므로, 방금 끝난 호출의 비용이 usage 에 반영되기까지 짧은 지연이 있을 수 있다.

오류

상태error_type언제
401invalid_api_keyAuthorization 헤더가 없거나 형식이 틀림. 우리 접두사(sk-mo-v1-/sk-mo-mgmt-v1-)가 아님. 존재하지 않는 키. 사용자가 끈(disabled) 키. 폐기된(revoked) 키
401expired_api_keyexpires_at 이 지남
402insufficient_credits키가 suspended_no_credit 상태. metadata.balance_krw 에 현재 잔액이 실린다. 충전하면 자동으로 풀린다
403key_suspended관리자가 정지한 키(suspended_admin). 충전해도 풀리지 않는다
500server그 밖의 서버 오류

오류 본문은 모든 경로에서 같은 형상이다.

json
{
  "error": {
    "code": 401,
    "message": "API 키가 올바르지 않습니다.",
    "metadata": { "error_type": "invalid_api_key" }
  }
}

관련 문서

마지막 수정 2026. 9. 5.