작업 생성 API
요청 본문
배치 요청 본문은 snake_case(
process_type)를 사용합니다 — 인라인 Guard API의 processType(camelCase)과 표기가 다릅니다.202 Accepted
job_id를 보관해 조회에 사용합니다.
검증 시점 — 접수 시점에는 인증 · Kill Switch · process_type · 허용 범위만 동기로 검증합니다(실패 시 작업이 만들어지지 않고 즉시 거부됩니다). 원본의 존재 · 크기 · 형식은 처리 시점에 검사되어, 문제가 있으면 작업이 FAILED로 확정됩니다. 배치 오류를 참고하세요.
재시도와 중복 — 멱등 토큰은 없습니다. 동일 요청을 재전송하면 각각 별개의 작업이 생성됩니다. 응답 유실 시 중복 접수될 수 있으나, 같은 입력·정책의 산출물이 같은 이름으로 원자적으로 덮어써지므로 tgt의 최종 상태는 동일합니다. 접수된 작업의 job_id를 잃었다면 아래 원본 주소 검색으로 복구하세요.
작업 조회 API
200
- 조회는 해당 작업을 생성한 프로젝트의 API Key로만 가능합니다.
- Kill Switch 발동 중에는 작업 생성과 조회가 모두 거부됩니다.
- 작업 조회의 보존 기간은 운영 정책을 따르며, 지난 작업의 이력은 Opticon에서 확인합니다 — 각 작업의 트레이스에 접수 정보(
src_s3_url·tgt_s3_url·process_type·job_id)와 판정 · 오류가 함께 기록됩니다.
원본 주소로 작업 검색
job_id를 잃은 경우 원본 주소로 최근 작업을 검색해 복구합니다:
results 미포함 — 상세는 job_id 단건 조회로 확인하세요).
폴링 패턴
1
작업 생성
POST /v1/guard/s3를 호출하고 응답의 job_id를 보관합니다.2
주기 조회
GET /v1/guard/s3/jobs/{job_id}를 주기적으로 호출합니다. status가 PENDING / PROCESSING이면 계속 대기합니다.3
확정 상태 분기
COMPLETED이면 action으로 분기하고(PASS / MASK는 tgt_s3_url에서 산출물 수거, BLOCK은 산출물 없음 — 사유는 results), FAILED이면 error.code로 분기합니다.