Skip to main content
バッチ連携の骨格は、ジョブの作成 → 定期照会(ポーリング)→ 成果物の回収という 3 ステップです。どちらの API も同一の API Key で認証します。

ジョブ作成 API

リクエストヘッダー リクエストボディ
バッチのリクエストボディは snake_caseprocess_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_urltgt_s3_urlprocess_typejob_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 で分岐します。