Skip to main content
Webhooks deliver HTTP POST callbacks to your server when order processing completes or fails. Use webhooks instead of polling the Get Order endpoint — your server gets notified the moment a result is ready.

Setting up webhooks

1

Register a webhook endpoint

You can create a webhook endpoint via the API or the BIZ MORI Dashboard. The example uses a live API key and creates a live endpoint. To create one via the API, use the Create Webhook endpoint:
Response:
Save the secret immediately — it is shown only once and cannot be retrieved again. You need it to verify every incoming webhook signature.
2

Implement your endpoint

Your webhook handler must:
  • Accept POST requests with a JSON body
  • Respond with a 2xx status code within 5 seconds
  • Verify the X-MoriBiz-Signature header before processing
3

Verify signatures

Every request includes an X-MoriBiz-Signature header. See Signature Verification below for implementation in your language.

Testing webhooks

To receive test-order events, register a separate test endpoint from 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 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.
  • An isTest: true endpoint receives test order events only.
  • An isTest: false endpoint receives live order events only.
  • Test webhook payloads use the same event names, HMAC-SHA256 signature, timeout, and retry behavior as live webhooks.
  • Anti-AI and Watermark Embed test events use downloadUrl: null because test processing does not create a result file.
Test endpoint CRUD, event listing, and retry operations use the same owner and test-mode isolation described below.

Event types

Webhook payload

All webhook payloads follow this structure:

Completed event — common fields

Failed event — common fields

Anti-AI / Watermark Embed — additional fields (completed)

Watermark Extract — additional fields (completed)

The status field is always complete. Use statusCode to determine the detection result. The payload exposes text only: it never includes MID, midDecimal, or midHex.

AI Detection — additional fields (completed)

Signature verification

Verify webhook authenticity by checking the X-MoriBiz-Signature header. Always verify before processing the event.

Retry policy

BIZ MORI uses a multi-layered retry system to ensure reliable webhook delivery.

Initial retry

If your endpoint doesn’t return a 2xx status code, BIZ MORI immediately retries:

Scheduler-based retry

If all initial retries fail, the event enters a scheduler-based retry queue with increasing intervals: After all scheduler-based retries are exhausted, the event is marked as FAILED. You can view failed events using the List Webhook Events endpoint.

Manual resend API

Regardless of the automatic retry process, you can manually resend webhooks at any time using the resend APIs:

Failure notification email

When initial webhook delivery fails, BIZ MORI sends a failure notification email to the account owner. This email is sent at most once per day to avoid excessive notifications.

Managing webhooks

Test API key scope

A test API key can manage only test endpoints owned by the same owner. It can list, get, create, update, and delete those endpoints; list their events; retry one failed event; and retry failed events in a date range of at most seven days. Event responses do not add delivery-log response bodies.
  • On create, omitting isTest or setting it to true creates a test endpoint. Setting isTest: false returns AUTH_FORBIDDEN.
  • On update, omitting isTest keeps test mode and true is allowed. Setting isTest: false returns AUTH_FORBIDDEN.
  • A live endpoint ID or another owner’s endpoint ID returns WEBHOOK_NOT_FOUND; this does not disclose whether that endpoint exists.
  • An event ID outside an accessible endpoint returns WEBHOOK_EVENT_NOT_FOUND.
Live API keys and the Dashboard keep their existing ability to choose isTest and manage the owner’s live and test endpoints. Secret one-time display, URL validation, HMAC signatures, and the retry policy are unchanged.