sk_test_ プレフィックスの自動発行テスト API キーを使用すると、本番 API キーを使う前に連携を検証できます。
テスト API キーは本番 API キーと同じ Bearer 認証を使用しますが、Anti-AI、watermark、AI Detection の処理は実行しません。結果ファイルも作成されず、顧客のクレジットも消費されません。
永続テスト注文とテスト Webhook は環境ごとに有効化されます。保存されない仮の注文だけが返される場合、その環境では従来のモック動作が使用されています。処理品質の確認や結果ファイルのダウンロードが必要な場合は、本番 API キーを使用してください。
テスト注文のライフサイクル
1
注文を作成する
本番連携で使用するものと同じ注文作成エンドポイントを呼び出します。
Authorization ヘッダーにテストキーを渡し、idempotencyKey を指定してください。論理注文ごとに新しい UUIDv4 を生成し、ネットワーク障害後に同じリクエストを再試行する場合にだけ再利用してください。2
テストファイルをアップロードする
アップロード方式のテスト注文では、注文レスポンスの テストアップロードのデフォルト上限は 50 MiB です。アップロード URL の有効期限が切れても注文がアップロード待ちの場合は、アップロード URL の再発行 を使用してください。
uploadUrl にファイルを送信します。テスト用のアップロード URL は PUT /api/v2/test-uploads/{token} ルートを使用します。アップロード URL には独自の認証情報が含まれています。API キーヘッダーを追加しないでください。BIZ MORI はリクエストストリームを受け取り、アップロード完了を記録した後、ファイル内容を破棄します。3
必要な場合に確認する
Anti-AI のアップロード方式と AI Detection では、アップロード後に確認エンドポイントを呼び出します。Watermark Embed と Watermark Extract は、必要なアップロードが完了すると開始されます。Anti-AI の URL 方式は注文作成時に開始されます。
4
状態の遷移を確認する
テスト注文も本番注文と同じ状態の形式に従います。
pending → inProgress → complete または failedシミュレーション処理の遅延は約 5 秒です。注文詳細の取得 をポーリングするか、環境で Webhook が有効になっている場合はテスト Webhook を使用してください。サービスごとのフロー
Watermark Embed または Watermark Extract では確認エンドポイントを呼び出さないでください。アップロード完了後に処理が開始されるため、確認リクエストは失敗します。
決定的な結果を選択する
入力ファイル名を使うと、外部処理サービスに依存せずに成功・失敗状態を検証できます。
サフィックスがない場合、Anti-AI と Watermark Embed は成功し、Watermark Extract は watermark を検出せず、AI Detection は確率
0.02 を返します。複数ファイルの注文で 1 つでも _fail を使用すると、注文は失敗します。
Watermark Extract では、detected と not_detected は検査対象ファイル名(file.fileName)だけで決まります。元ファイルの _detected サフィックスは結果に影響しませんが、どちらのファイルでも _fail があると注文は失敗します。
テスト Webhook
Dashboard、本番 API キー、またはテスト API キーで、同じ所有者のテスト Webhook エンドポイントを作成できます。テストキーではisTest を省略するか true に設定でき、isTest: false は 403 AUTH_FORBIDDEN を返します。
- テスト API キーでは、同じ所有者のテストエンドポイントの作成、一覧・詳細取得、更新、削除、イベント取得、失敗イベントの再送を実行できます。本番モードと別所有者のリソースは公開されません。
isTest: trueのエンドポイントはテスト注文イベントだけを受信します。isTest: falseのエンドポイントは本番注文イベントだけを受信します。- テスト Webhook のイベント名、HMAC-SHA256 署名、再試行動作は本番 Webhook と同じです。
- 結果ファイルを作成しないため、Anti-AI と Watermark Embed のテストイベントでは
downloadUrl: nullになります。
Watermark の結果、ダウンロード、レポート
アップロードが完了すると、Watermark 注文はinProgress になり、約 5 秒後に complete または failed になります。注文取得の outputs と result は本番注文と同じ形式です。
- ダウンロード URL は、入力形式(PNG、JPG、WEBP、PDF)に合った固定のサンプルファイルを返します。出力が複数ある注文ではサンプル ZIP ファイルを返します。実際に watermark を挿入した結果ファイルではありません。
- 検出結果が
detectedの場合、watermarkTextはMORI TEST WATERMARK、reportSupportedはtrueです。 - レポートは 1 ページのサンプル PDF です。実際の検出結果は含まれず、
localeによって内容は変わりません。 not_detectedの注文はREPORT_NOT_AVAILABLE、未完了または失敗した注文はORDER_NOT_COMPLETED、Watermark Embed の注文はORDER_TYPE_NOT_MATCHで拒否されます。別所有者の注文と本番注文はORDER_NOT_FOUNDを返します。
- テストのレポートリクエストは即座に
200 completedを返します。202 queuedやprocessingは返さず、クレジットも消費しません。 - テストレポートは保存されないため、注文取得の
reports配列は常に空です。 - 同じ
idempotencyKeyを再送すると、リクエスト本文を比較せずに既存の注文を返すため、409は発生しません。
API の動作と制限
テスト注文と本番注文は分離されています。テストキーでは本番注文を読み取ったり変更したりできず、本番キーでもテスト注文を読み取ったり変更したりできません。
テスト API キーは次の処理を実行しません。
- 画像またはドキュメントの実処理
- クレジットの予約または消費
- ダウンロード可能な結果ファイルの作成(Watermark のダウンロードおよびレポートのエンドポイントが返す固定サンプルファイルを除く)
- 本番 Webhook エンドポイントへのイベント送信