Integration Guide
/
Integration
Integration
Authenticate using your MORI API Key.
App Authentication
Your application must authenticate using an API key in order to access the MORI API.
For certain API calls, this API key acts as a credential and must be sent to the server.
You can refer to the onboarding steps for issuing an API key in the image below:
API Request Retry
API requests can fail for various reasons — for example, network errors, rate limits, or service delays.
In such cases, it is recommended to retry the request using the following approach:
Exponential Backoff: Retry the request at increasingly longer intervals each time it fails.
Jitter: Adding a random delay within a certain range helps prevent multiple requests from clustering at the same time.
Using an idempotency key ensures that even if the same request is sent multiple times, the server processes it only once.
Idempotency Guarantee
Because requests can fail for unclear reasons, such as network issues, idempotency is extremely important.
APIs that support idempotency process a repeated request only once, even if it is sent multiple times.
This increases the safety and reliability of the system.
For example, if a network error occurs during an Anti-AI filter application order, sending the request again with the same idempotency key will still result in the operation being processed only once.
It is recommended to use a UUID for the idempotency key.
In fact, the Biz service also manages idempotency keys using UUID v4.
Timeout
API requests have a default timeout of 30 seconds.
If you configure the same timeout value in your application, it can quickly retry when a request fails, resulting in a more stable processing flow.
Server Response Format
Success Response
{ "success": true, "message": "some message", "data": { /* Include response data if necessary */ }, "meta": { /* Include meta information if necessary */ } }
Fail Response
{ "success": false, "message": "some message", "code": "some code", "errors": { "message": "detailed description (optional)", "propertyName": "missing field name (optional)" } }
Webhook
When a major resource state change occurs, the webhook feature notifies the customer’s app or service of the update.
When an event occurs, an HTTP POST request is sent to the pre-registered webhook URL.
This allows the customer’s system to automatically perform any necessary follow-up actions.
Integration Guide
/
Integration
Integration
Authenticate using your MORI API Key.
App Authentication
Your application must authenticate using an API key in order to access the MORI API.
For certain API calls, this API key acts as a credential and must be sent to the server.
You can refer to the onboarding steps for issuing an API key in the image below:
API Request Retry
API requests can fail for various reasons — for example, network errors, rate limits, or service delays.
In such cases, it is recommended to retry the request using the following approach:
Exponential Backoff: Retry the request at increasingly longer intervals each time it fails.
Jitter: Adding a random delay within a certain range helps prevent multiple requests from clustering at the same time.
Using an idempotency key ensures that even if the same request is sent multiple times, the server processes it only once.
Idempotency Guarantee
Because requests can fail for unclear reasons, such as network issues, idempotency is extremely important.
APIs that support idempotency process a repeated request only once, even if it is sent multiple times.
This increases the safety and reliability of the system.
For example, if a network error occurs during an Anti-AI filter application order, sending the request again with the same idempotency key will still result in the operation being processed only once.
It is recommended to use a UUID for the idempotency key.
In fact, the Biz service also manages idempotency keys using UUID v4.
Timeout
API requests have a default timeout of 30 seconds.
If you configure the same timeout value in your application, it can quickly retry when a request fails, resulting in a more stable processing flow.
Webhook
When a major resource state change occurs, the webhook feature notifies the customer’s app or service of the update.
When an event occurs, an HTTP POST request is sent to the pre-registered webhook URL.
This allows the customer’s system to automatically perform any necessary follow-up actions.
Server Response Format
Success Response
{ "success": true, "message": "some message", "data": { /* Include response data if necessary */ }, "meta": { /* Include meta information if necessary */ } }
Fail Response
{ "success": false, "message": "some message", "code": "some code", "errors": { "message": "detailed description (optional)", "propertyName": "missing field name (optional)" } }
Integration Guide