
Rivya API는 자체 제품, 스크립트, 워크플로에서 Rivya 모델 기능을 사용하기 위한 개발자 경로입니다.
Rivya Studio와 분리된 별도 제품은 아닙니다. Rivya 전체에서 사용자가 보는 것과 같은 계정 경계, 같은 크레딧 지갑, 같은 공개 모델 레이어를 사용합니다. 차이는 작업을 시작하는 방식입니다. Studio에서 클릭으로 진행하는 대신, 애플리케이션이 API 키로 요청을 보냅니다.
엔드포인트 세부 사항이 필요하다면 Rivya API 개요와 Rivya API 빠른 시작부터 보세요. 이 글은 제품 수준의 설명입니다. API가 무엇을 위한 것인지, 어디에 맞는지, 언제 첫 경로가 아니어야 하는지를 다룹니다.
짧게 말하면
Rivya API v1은 로그인한 계정이 API 키를 만들고 웹 인터페이스 밖에서 Rivya 모델 기능을 호출할 수 있게 합니다.
현재 API 표면에는 다음이 포함됩니다.
- API 모델 목록을 통한 모델 탐색
- 비동기 이미지, 비디오, 오디오 생성 작업
- 참고 미디어가 필요한 모델을 위한 Files API 업로드
- 공개 작업 ID로 생성 상태 폴링
- 계정 크레딧 확인
- 선택적 SSE 스트리밍을 포함한 Chat API 턴
- 생성 완료용 서명된 웹훅
- 클라이언트 래퍼를 원하는 팀을 위한 TypeScript SDK 베타
공개 개발자 허브는 Developers입니다. 안내형 개요, API 키 설정 링크, 안전한 디버거 흐름이 필요할 때 가장 좋은 진입점입니다.
Rivya에 API가 있는 이유
Studio는 사람이 아직 모델을 고르고, 프롬프트를 다듬고, 결과를 검토하고, 다음 행동을 결정해야 할 때 유용합니다.
API는 그 결정이 반복 가능한 제품 흐름이나 운영 워크플로로 바뀌었을 때 유용합니다.
일반적인 예시는 다음과 같습니다.
- 사용자가 브리프를 제출한 뒤 제품이 이미지 변형을 생성해야 하는 경우
- 마케팅 워크플로가 구조화된 캠페인 입력에서 시각 초안을 만들어야 하는 경우
- 내부 도구가 누군가에게 브라우저를 열게 하지 않고 비디오나 오디오 작업을 제출해야 하는 경우
- 지원 또는 콘텐츠 시스템이 자체 인터페이스 안에서 채팅 모델 턴을 원할 때
- 백엔드 서비스가 생성 작업 완료 시 서명된 콜백을 받고 싶을 때
이런 경우 Rivya API는 결제, 모델 선택, 작업 상태를 위해 별도 스택을 강제하지 않고 같은 Rivya 계정에 작업을 연결해 둡니다.
API가 대체하지 않는 것
API가 Rivya를 직접 사용할 모든 이유를 대체하지는 않습니다.
다음 상황에서는 Studio나 공개 작업 화면을 사용하세요.
- 프롬프트에 아직 사람의 탐색이 필요한 경우
- 모델 선택이 안정되지 않은 경우
- 크리에이터가 결과물을 시각적으로 비교해야 하는 경우
- 프로젝트가 저장된 히스토리와 수동 검토에 의존하는 경우
- 팀이 어떤 입력과 출력 형식을 반복 가능한 흐름으로 만들지 아직 결정하지 않은 경우
워크플로가 자동화할 만큼 명확해졌을 때 API를 사용하세요.
이 경계가 중요합니다. 모호한 창작 질문은 보통 먼저 Studio에 있어야 합니다. 예측 가능한 입력을 가진 알려진 제품 흐름은 API로 옮길 수 있습니다.
주요 구성 요소
API를 여섯 개의 연결된 조각으로 생각하면 됩니다.
| 구성 요소 | 처리하는 것 | 다음에 읽을 문서 |
|---|---|---|
| API 키 | 계정에서 서버 간 접근 | API 인증 |
| Models | 공개 모델 ID와 준비 상태 정보 | API 모델 |
| 생성 | 비동기 이미지, 비디오, 오디오 작업 | 생성 만들기 |
| Files | 참고 이미지, 비디오, 오디오 업로드 | Files API |
| Chat | 비스트리밍 또는 스트리밍 채팅 턴 | Chat API |
| 웹훅 | 생성 작업용 서명된 완료 이벤트 | API 웹훅 |
요청과 응답 형태의 기준은 API 문서입니다. 이 글은 먼저 어떤 조각이 필요한지 판단하는 데 도움을 주기 위한 것입니다.
크레딧 작동 방식
API 사용량은 Studio와 같은 Rivya 계정 크레딧 지갑에서 차감됩니다.
즉 API는 익명 모델 프록시가 아닙니다. 요청은 Rivya 계정에 속하고, 그 계정이 만든 API 키를 사용하며, API 크레딧에 설명된 같은 제품 수준 크레딧 경계를 따릅니다.
팀에는 이 구조가 유용합니다. Studio 실험과 API 사용량이 하나의 운영 모델 안에 남기 때문입니다. 모델을 수동으로 테스트한 뒤, 반복 가능한 부분을 두 번째 결제 레이어 없이 통합으로 옮길 수 있습니다.
파일이 들어가는 방식
일부 모델은 텍스트만으로 실행할 수 있습니다. 다른 모델은 참고 이미지, 비디오, 오디오 파일이 필요합니다.
API 통합에서는 이런 참고 자료를 Files API를 통해 처리해야 합니다. 업로드는 지원되는 모델 파라미터에 전달할 수 있는 관리형 파일 레코드를 만듭니다.
실무 규칙은 간단합니다.
- 모델이 텍스트 전용 입력을 받는다면 생성 엔드포인트부터 시작하세요
- 모델에 참고 미디어가 필요하다면 먼저 파일을 업로드하세요
- 모델이 이미지 첨부를 받는 채팅 모델이라면 Chat API와 파일 ID를 사용하세요
브라우저 전용 업로드 흐름이나 저장된 Studio 세션을 중심으로 통합을 설계하지 마세요. API에는 자체 공개 파일 경계가 있습니다.
Webhooks가 도움이 되는 곳
폴링은 가장 쉬운 첫 통합 경로입니다. 생성 작업을 제출하고, 공개 작업 ID를 저장한 뒤, 성공하거나 실패할 때까지 폴링합니다.
Webhooks는 통합이 더 운영 환경에 가까워질 때 유용해집니다.
- 모든 작업을 폴링하는 worker를 두고 싶지 않은 경우
- 생성이 끝났을 때 앱에서 레코드를 업데이트해야 하는 경우
- 안전하게 재시도할 수 있는 서명된 이벤트를 원할 때
- 실패한 작업을 명확한 복구 경로로 보내야 할 때
서명된 이벤트 계약은 API 웹훅를 사용하세요. 웹훅 수신기는 좁게 유지하세요. 서명을 검증하고, 중복 이벤트를 처리하며, 로그에 비밀 값을 넣지 마세요.
좋은 첫 API 프로젝트
가장 좋은 첫 API 프로젝트는 보통 작고 구체적입니다.
예를 들면 다음과 같습니다.
- settings에서 API 키 만들기
- 모델 목록 호출하기
- 사용 가능한 모델 하나 선택하기
- 멱등성 키로 생성 작업 하나 제출하기
- 상태 엔드포인트 폴링하기
- 전후 크레딧 확인하기
- 그다음에야 Files API, Chat API, Webhooks 추가하기
이 경로는 모든 API 기능을 첫 테스트에 섞지 않고도 작동하는 통합을 제공합니다.
API가 잘못된 출발점인 경우
다음 상황에서는 API가 적절한 첫 단계가 아닐 가능성이 큽니다.
- 팀이 아직 모델 패밀리를 선택하지 않은 경우
- 원하는 출력이 실행마다 계속 바뀌는 경우
- 프롬프트가 수동 취향 판단과 검토에 의존하는 경우
- 통합이 크레딧 사용량을 알아야 하는 사람들에게서 그 정보를 숨기게 되는 경우
- 제품에 자동화보다 공개 데모가 먼저 필요한 경우
이런 경우 Image, Video, Audio, Chat, 또는 AI Models에서 시작하세요. 경로가 반복 가능해지면 안정된 부분을 API로 옮기세요.
다음에 볼 곳
- 공개 API 허브와 디버거는 Developers를 여세요.
- 첫 안전한 요청을 만들려면 Rivya API 빠른 시작을 읽으세요.
- 서버에 키를 넣기 전에는 API 인증을 읽으세요.
- 모델 ID를 고르기 전에는 API 모델을 읽으세요.
- 제품 경계가 아직 불명확하다면 Studio 대신 Rivya API를 사용할 때를 읽으세요.
- 전체 이미지, 비디오, 오디오, 채팅 통합을 계획 중이라면 Rivya API로 멀티모달 AI 워크플로를 구축하는 방법을 읽으세요.


