Felo API PlatformFelo API Platform

가이드

오류, 속도 제한 및 재시도

오류 응답과 속도 제한 헤더를 읽고 안전하게 재시도하며 일반적인 장애를 진단하세요.

모든 Felo API는 안정적인 오류 코드와 request ID가 담긴 JSON 오류 본문을 반환합니다. 먼저 HTTP 상태, 그다음 code, 마지막으로 message를 읽으세요.

오류 envelope

현재 프로덕션 응답은 HTTP 상태를 status로 사용합니다.

{
  "status": 401,
  "code": "UNAUTHORIZED",
  "message": "Invalid API Key",
  "request_id": "202610221444486982113280416060637185"
}
필드의미
statusHTTP 상태 코드이며 본문에도 같은 값이 반복됩니다
code기계가 읽을 수 있는 오류 코드
message사람이 읽을 수 있는 설명
request_id이 요청의 불투명 식별자. 지원 요청에 포함하세요

일부 오래된 endpoint 예시는 status: "error"와 다른 code 문자열을 사용합니다. message의 정확한 표현이 아니라 HTTP 상태와 code를 기준으로 분기하세요.

일반적인 코드

HTTPCode의미해야 할 일
400Endpoint별 검증 코드파라미터가 없거나 잘못됨요청을 수정하세요. 그대로 재시도하지 마세요
401UNAUTHORIZEDAPI key가 없거나, 잘못되었거나, 만료되었거나, 폐기됨Authorization: Bearer $FELO_API_KEY를 보내세요. 폐기되었다면 key를 교체하세요
402INSUFFICIENT_CREDITS서비스 크레딧 부족Console Billing에서 충전한 뒤 재시도하세요
404Endpoint별알 수 없는 모델, 작업, 라우트모델 ID 또는 작업 ID와 endpoint 경로를 확인하세요
429RATE_LIMITED속도 제한을 초과함Retry-After를 기다린 뒤 재시도하세요
5xxCHAT_FAILED, *_FAILED, SERVICE_UNAVAILABLE업스트림 또는 서비스 장애backoff와 함께 재시도하세요. 계속되면 지원팀에 문의하세요

Endpoint 참조 문서에는 해당 endpoint 고유의 코드가 나열되어 있습니다. Chat API 오류 또는 호출하는 endpoint의 참조부터 확인하세요.

Request ID

Felo 오류 본문에는 request_id가 포함됩니다. endpoint, HTTP 상태, 오류 코드, 모델 ID, 작업 ID와 함께 기록하세요. 전체 API key는 절대 기록하지 마세요.

Model API는 선택적 X-Request-Id 요청 헤더도 받습니다. 보내면 진단을 위해 응답에 그대로 돌아오므로 자기 로그와 요청을 연결할 수 있습니다. 보내지 않았다면 반환된 request_id를 사용하세요.

속도 제한

/v2/chat은 문서화된 강제 속도 제한이 있는 유일한 Felo endpoint입니다.

  • API key당 1분 창.
  • 사용자당 1분 창.
  • 사용자당 1시간 창.

유효한 유료 Felo 구독(엔터프라이즈 포함) 사용자는 면제되며 X-RateLimit-* 헤더를 받지 않습니다. 구독 상태를 확인할 수 없으면 제한이 그대로 적용됩니다.

헤더의미
X-RateLimit-Limit현재 적용되는 가장 엄격한 차원의 한도
X-RateLimit-Remaining세 차원 중 최소 잔여 할당량
X-RateLimit-Reset현재 창이 재설정되는 Unix 타임스탬프(초)
Retry-After429일 때 권장 대기 시간(초)

다른 /v2/** endpoint에는 현재 강제 속도 제한이 없습니다. Model API 요청은 업스트림 공급자의 제한을 받아 429로 나타날 수 있습니다.

숫자 한도를 하드코딩하지 마세요. 각 응답의 헤더를 읽으세요.

재시도 정책

상황재시도?
400, 401, 402, 404아니요. 먼저 요청, key, 잔액을 고치세요.
429예. Retry-After 또는 X-RateLimit-Reset 이후에.
5xx, 타임아웃, 연결 재설정예. 지수 backoff와 jitter를 사용하세요.
스트리밍 연결이 응답 중간에 끊김애플리케이션이 중복 생성을 감당할 수 있을 때만 재시도하세요.

권장 루프:

  1. 멱등이거나 안전하게 반복할 수 있는 요청만 재시도하세요.
  2. 지수 backoff를 사용하세요. 약 1초에서 시작해 두 배로 늘리고 30초에서 멈추세요.
  3. 무작위 jitter를 더해 클라이언트가 동시에 재시도하지 않게 하세요.
  4. 몇 번 시도한 뒤 중단하고 오류를 밖으로 전달하세요.
  5. 429에서는 자체 일정 대신 Retry-After를 따르세요.

디버깅 순서

  1. key가 있는지, 폐기되지 않았는지 확인합니다.
  2. 같은 key로 GET /api/v1/models를 호출해 인증을 확인합니다.
  3. 대상 endpoint에 가장 작은 유효 요청을 보냅니다.
  4. streaming, tools, 큰 입력을 하나씩 추가합니다.
  5. 비동기 작업은 다시 제출하기 전에 작업 상태를 확인합니다.

관련 문서