Skip to main content
배치 연동의 골격은 작업 생성 → 주기 조회(폴링) → 산출물 수거 세 단계입니다. 두 API 모두 동일한 API Key로 인증합니다.

작업 생성 API

요청 헤더 요청 본문
배치 요청 본문은 snake_case(process_type)를 사용합니다 — 인라인 Guard APIprocessType(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를 잃은 경우 원본 주소로 최근 작업을 검색해 복구합니다:
해당 원본 객체로 접수된 최근 작업 목록을 최신순으로 반환합니다(기본 최대 20건, results 미포함 — 상세는 job_id 단건 조회로 확인하세요).

폴링 패턴

1

작업 생성

POST /v1/guard/s3를 호출하고 응답의 job_id를 보관합니다.
2

주기 조회

GET /v1/guard/s3/jobs/{job_id}를 주기적으로 호출합니다. statusPENDING / PROCESSING이면 계속 대기합니다.
3

확정 상태 분기

COMPLETED이면 action으로 분기하고(PASS / MASKtgt_s3_url에서 산출물 수거, BLOCK은 산출물 없음 — 사유는 results), FAILED이면 error.code로 분기합니다.