Integration Guide
/
Integration
Integration
Apply the Anti-AI Filter using the MORI API.
App Authentication
To allow the client’s application to access the MORI API, authentication using an access token is required.
When calling certain APIs, this access token serves as a credential and must be sent to the server.
You can check the onboarding process for obtaining an access token in the image below:
API Request Retry
An API request can fail for various reasons, such as network errors, rate limits, or service delays.
In such cases, it is recommended to retry the request as follows:
Exponential Backoff: Retry the request with progressively longer intervals after each failure.
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
Since requests can fail for unclear reasons, such as network issues, idempotency is very important.
APIs that support idempotency process identical requests only once, even if they are sent multiple times, improving system stability and reliability.
The main APIs in MORI that guarantee idempotency are as follows:
POST /api/v2/orders
(Apply Anti-AI Filter Order Creation, S3 Image Upload)
POST /api/v2/orders/with-urls
(Apply Anti-AI Filter Order Creation, External Public Image URLs)
POST /api/v2/orders/confirm
(Apply Anti-AI Filter Order Check)
For example, if a network error occurs during an Anti-AI Filter order request, resending the same request with the same idempotency key will still result in it 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.
An idempotency key remains valid for {n} years after successful use, after which it can be reused.
Timeout
By default, API requests have a 30-second timeout.
Setting the same timeout value in your application allows for quick retries in case of failure, resulting in a more stable processing flow.
Server Response Format
By default, API requests have a 30-second timeout.
Setting the same timeout value in your application allows for quick retries when a request fails, helping to maintain a more stable processing flow.
Success Response O
{
"success": true,
"message": "some message",
"data": { /* Include response data if necessary */ },
"meta": { /* Include meta information if necessary */ }
}
Error Response X
{
"success": false,
"message": "some message",
"code": "some code",
"errors": {
"message": "Detailed Explanation (optional)",
"propertyName": "Missing Field Name (optional)"
}
}
Web hook
MORI provides a webhook feature that notifies your app or service whenever a major resource state change occurs.
Typical examples of such events include the following:
ORDER.PROCESSED
: Triggered when an order is processed.
When an event occurs, an HTTP POST request is sent to the pre-registered webhook URL.
This allows your system to automatically perform follow-up processing.
Integration Guide
/
Integration
Integration
Apply the Anti-AI Filter using the MORI API.
App Authentication
To allow the client’s application to access the MORI API, authentication using an access token is required.
When calling certain APIs, this access token serves as a credential and must be sent to the server.
You can check the onboarding process for obtaining an access token in the image below:
API Request Retry
An API request can fail for various reasons, such as network errors, rate limits, or service delays.
In such cases, it is recommended to retry the request as follows:
Exponential Backoff: Retry the request with progressively longer intervals after each failure.
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
Since requests can fail for unclear reasons, such as network issues, idempotency is very important.
APIs that support idempotency process identical requests only once, even if they are sent multiple times, improving system stability and reliability.
The main APIs in MORI that guarantee idempotency are as follows:
POST /api/v2/orders
(Apply Anti-AI Filter Order Creation, S3 Image Upload)
POST /api/v2/orders/with-urls
(Apply Anti-AI Filter Order Creation, External Public Image URLs)
POST /api/v2/orders/confirm
(Apply Anti-AI Filter Order Check)
For example, if a network error occurs during an Anti-AI Filter order request, resending the same request with the same idempotency key will still result in it 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.
An idempotency key remains valid for {n} years after successful use, after which it can be reused.
Timeout
By default, API requests have a 30-second timeout.
Setting the same timeout value in your application allows for quick retries in case of failure, resulting in a more stable processing flow.
Server Response Format
By default, API requests have a 30-second timeout.
Setting the same timeout value in your application allows for quick retries when a request fails, helping to maintain a more stable processing flow.
Success Response O
{
"success": true,
"message": "some message",
"data": { /* Include response data if necessary */ },
"meta": { /* Include meta information if necessary */ }
}
Error Response X
{
"success": false,
"message": "some message",
"code": "some code",
"errors": {
"message": "Detailed Explanation (optional)",
"propertyName": "Missing Field Name (optional)"
}
}
Web hook
MORI provides a webhook feature that notifies your app or service whenever a major resource state change occurs.
Typical examples of such events include the following:
ORDER.PROCESSED
: Triggered when an order is processed.
When an event occurs, an HTTP POST request is sent to the pre-registered webhook URL.
This allows your system to automatically perform follow-up processing.
Integration Guide
/
Integration
Integration
Apply the Anti-AI Filter using the MORI API.
App Authentication
To allow the client’s application to access the MORI API, authentication using an access token is required.
When calling certain APIs, this access token serves as a credential and must be sent to the server.
You can check the onboarding process for obtaining an access token in the image below:
API Request Retry
An API request can fail for various reasons, such as network errors, rate limits, or service delays.
In such cases, it is recommended to retry the request as follows:
Exponential Backoff: Retry the request with progressively longer intervals after each failure.
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
Since requests can fail for unclear reasons, such as network issues, idempotency is very important.
APIs that support idempotency process identical requests only once, even if they are sent multiple times, improving system stability and reliability.
The main APIs in MORI that guarantee idempotency are as follows:
(Apply Anti-AI Filter Order Creation, S3 Image Upload)
POST /api/v2/orders
(Apply Anti-AI Filter Order Creation, External Public Image URLs)
POST /api/v2/orders/with-urls
(Apply Anti-AI Filter Order Check)
POST /api/v2/orders/confirm
For example, if a network error occurs during an Anti-AI Filter order request, resending the same request with the same idempotency key will still result in it 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.
An idempotency key remains valid for {n} years after successful use, after which it can be reused.
Timeout
By default, API requests have a 30-second timeout.
Setting the same timeout value in your application allows for quick retries in case of failure, resulting in a more stable processing flow.
Server Response Format
By default, API requests have a 30-second timeout.
Setting the same timeout value in your application allows for quick retries when a request fails, helping to maintain a more stable processing flow.
Success Response O
{
"success": true,
"message": "some message",
"data": { /* Include response data if necessary */ },
"meta": { /* Include meta information if necessary */ }
}
Error Response X
{
"success": false,
"message": "some message",
"code": "some code",
"errors": {
"message": "Detailed Explanation (optional)",
"propertyName": "Missing Field Name (optional)"
}
}
Web hook
MORI provides a webhook feature that notifies your app or service whenever a major resource state change occurs.
Typical examples of such events include the following:
ORDER.PROCESSED
: Triggered when an order is processed.
When an event occurs, an HTTP POST request is sent to the pre-registered webhook URL.
This allows your system to automatically perform follow-up processing.
Getting Started
Integration Guide