오류

모든 오류는 같은 JSON 본문을 사용합니다. 실패한 요청을 HTTP 200으로 반환하는 일은 없습니다. 오류가 200 응답 안에 들어가는 두 가지 경우는 응답 안의 오류에서 설명합니다.

{
  "error": {
    "message": "Model \"example/unknown\" was not found.",
    "type": "not_found_error",
    "code": "model_not_found",
    "param": "model",
    "request_id": "req_0123456789abcdef0123456789abcdef",
    "doc_url": "https://example.com/docs/errors/#model_not_found"
  }
}

• message: 사람이 읽는 짧은 설명입니다.
• type: 오류 분류입니다.
• code: 프로그램이 사용하는 안정적인 식별자입니다. 분기에는 message가 아니라 code를 사용하세요.
• param: 오류의 원인이 된 요청 파라미터이며, 없으면 null입니다.
• request_id: 요청의 ID입니다. 지원을 요청할 때 함께 알려 주세요.
• doc_url: 이 페이지에서 해당 코드 항목으로 연결되는 링크입니다.
• details: 선택적인 기계 판독용 보충 정보입니다. 필드는 오류에 따라 다릅니다.
  • 허용 값이 정해져 있는 필드에서는 details.allowed에 허용되는 값이 나열됩니다.
  • 숫자가 범위를 벗어나면 details.minimum과 details.maximum에 허용 범위가 담깁니다.
  • 402에서는 details.limit_source가 balance 또는 key입니다. 나머지 필드에는 금액이 담기며, 키의 한도라면 기간과 details.resets_at도 담깁니다. 잔액과 API 키 사용 한도를 참고하세요.
  • 사용할 수 없는 참조 이미지 URL에서는 details.reason에 그 이유가 담깁니다.
  • 데이터 URI로 보낸 참조 이미지가 너무 크면 details.max_bytes가 허용 크기입니다.
  • payload_too_large에서는 details.max_bytes가 허용 크기입니다.
  • 작업을 기다리던 요청이 그 작업의 실패로 실패하면 details.job_id가 작업의 ID입니다.
  • 이미 끝난 작업을 취소하거나 파일이 없는 영상을 다운로드하는 것처럼 요청이 작업의 상태에 좌우되는 경우에는 details.status가 작업의 상태입니다.

오류를 200 응답 안에 담아 보고하는 경우는 두 가지입니다.

• 시작된 뒤에 실패하는 스트리밍 채팅 응답. 오류는 스트림 안의 이벤트로 도착합니다. 채팅을 참고하세요.
• 실패한 작업. 작업을 읽으면 200이 반환되고, 작업의 error 필드에 오류 응답과 같은 필드가 담깁니다. 작업을 참고하세요.

POST /v1/messages는 모든 오류를 Anthropic 형식으로 반환합니다. type은 error이고, 오류는 error에 들어 있으며, request_id는 최상위 필드입니다. 코드와 HTTP 상태는 아래 표와 같습니다. 채팅을 참고하세요.

각 코드는 자신의 행으로 연결되므로, doc_url의 앵커(#<code>)로 해당 항목이 열립니다.