Skip to main content
Use the automatically issued test API key with the sk_test_ prefix to validate your integration before you use a live API key. Test API keys use the same Bearer authentication as live keys, but they do not run Anti-AI, watermark, or AI Detection processing. They also do not create result files or consume customer credits.
Persistent test orders and test webhooks are enabled per environment. If your environment returns synthetic orders that are not retained, it is using the legacy mock behavior. Use a live API key when you need to evaluate processing quality or download a result file.

Test order lifecycle

1

Create an order

Call the same order creation endpoint that you use for a live integration. Send the test key in the Authorization header and provide an idempotencyKey. Generate a new UUIDv4 for each logical order, and reuse it only when retrying that same request after a network failure.
2

Upload the test file

For an upload-mode test order, send the file to the uploadUrl returned by the order response. A test upload URL uses the PUT /api/v2/test-uploads/{token} route.The upload URL carries its own authorization. Do not add an API key header. BIZ MORI consumes the request stream, records upload completion, and discards the file contents.
The default test upload limit is 50 MiB. Use Refresh presigned URLs when an upload URL expires and the order is still waiting for an upload.
3

Confirm when the service requires it

Call the confirm endpoint after the upload for Anti-AI upload mode and AI Detection. Watermark Embed and Watermark Extract start after their required uploads finish. Anti-AI URL mode starts when you create the order.
4

Observe the state transition

Test orders follow the same state shape as live orders:pending → inProgress → complete or failedThe simulated processing delay is about five seconds. Poll Get order, or use a test webhook endpoint when webhooks are enabled in your environment.
5

Inspect the test order

Use List orders, Recent usage statistics, and Get order details with the same test key. You see only test orders owned by the account associated with that key.

Service flows

Do not call a confirm endpoint for Watermark Embed or Watermark Extract. The request will fail because those services start after their uploads complete.
The Watermark v2 endpoints (POST /api/v2/orders/wtr-embed and POST /api/v2/orders/wtr-extract) are scheduled to end support at 09:00 KST on October 9, 2026 (00:00 UTC). Migrate to the v3 endpoints (/api/v3/orders/wtr-embed and /api/v3/orders/wtr-extract). This guide describes the v3 endpoints for Watermark Embed and Watermark Extract.

Choose a deterministic result

Use the input file name to exercise success and failure states without depending on an external processing service. Without a suffix, Anti-AI and Watermark Embed complete successfully, Watermark Extract reports no watermark, and AI Detection returns probability 0.02. If any file in a multi-file order uses _fail, the order fails. For Watermark Extract, only the name of the inspected file (file.fileName) selects detected or not_detected. A _detected suffix on the original file has no effect, but _fail on either file fails the order.

Test webhooks

Create an owned test webhook endpoint with the Dashboard, a live API key, or a test API key. A test key may omit isTest or set it to true; isTest: false returns 403 AUTH_FORBIDDEN:
  • A test API key can create, list, get, update, and delete test endpoints owned by the same owner, list their events, and retry failed events. Live-mode and other-owner resources remain hidden.
  • isTest: true endpoints receive test order events only.
  • isTest: false endpoints receive live order events only.
  • Test webhook payloads use the same event names, HMAC-SHA256 signature, and retry behavior as live webhooks.
  • Anti-AI and Watermark Embed test events use downloadUrl: null because no result file is created.
See Webhooks for owner and mode isolation, signature verification, event payloads, and retry rules.

Watermark results, downloads, and reports

After the uploads finish, a Watermark order moves to inProgress and then to complete or failed about five seconds later. Get order returns outputs and result in the same shape as a live order.
  • The download URL returns a fixed sample file that matches the input format: PNG, JPG, WEBP, or PDF. A multi-output order returns a sample ZIP file. The file is not your watermarked output.
  • A detected result returns watermarkText as MORI TEST WATERMARK and reportSupported as true.
  • The report is a one-page sample PDF. It does not contain your detection result, and the content does not change with locale.
  • Report requests fail with REPORT_NOT_AVAILABLE for a not_detected order, ORDER_NOT_COMPLETED for an order that is not complete or failed, and ORDER_TYPE_NOT_MATCH for a Watermark Embed order. Other owners’ orders and live orders return ORDER_NOT_FOUND.
Differences from live Watermark orders:
  • A test report request returns 200 completed immediately. It never returns 202 queued or processing, and it does not consume credits.
  • The reports array in Get order is always empty because test reports are not stored.
  • Reusing an idempotencyKey returns the existing order without comparing the request body, so it never returns 409.

API behavior and limitations

Test orders remain separate from live orders. A test key cannot read or modify live orders, and a live key cannot read or modify test orders. Test API keys do not:
  • run image or document processing;
  • reserve or consume credits;
  • create downloadable result files, except the fixed sample files returned by the Watermark download and report endpoints; or
  • send events to live webhook endpoints.
For authentication details, see Authentication. For error handling, see Error Codes.