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:
2
Implement your endpoint
Your webhook handler must:
- Accept
POSTrequests with a JSON body - Respond with a
2xxstatus code within 5 seconds - Verify the
X-MoriBiz-Signatureheader 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 omitisTest 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: trueendpoint receives test order events only. - An
isTest: falseendpoint 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: nullbecause test processing does not create a result file.
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)
Thestatus 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 theX-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 a2xx 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:- Single event resend: Retry a specific failed event using the Retry Webhook Event endpoint.
- Bulk resend: Retry all failed events within a date range (up to 7 days) using the Retry Failed Webhook Events endpoint.
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
isTestor setting it totruecreates a test endpoint. SettingisTest: falsereturnsAUTH_FORBIDDEN. - On update, omitting
isTestkeeps test mode andtrueis allowed. SettingisTest: falsereturnsAUTH_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.
isTest and manage the owner’s live and test endpoints. Secret one-time display, URL validation, HMAC signatures, and the retry policy are unchanged.