연동 안내
/
연동 기본 정보
연동 기본 정보
MORI API를 통해 Anti-AI 필터를 적용해보세요.
앱 인증
고객사의 애플리케이션이 MORI API에 접근하려면, 반드시 액세스 토큰을 사용한 인증이 필요해요.
일부 API를 호출할 때는 이 액세스 토큰이 자격 증명(Credential) 역할을 하며, 서버로 전송되어야 합니다.
액세스 토큰을 발급받는 온보딩 절차는 아래 이미지에서 확인할 수 있어요:
API 요청 재시도
API 요청은 다양한 이유로 실패할 수 있어요. 예를 들어, 네트워크 오류, 요청 속도 제한, 서비스 지연 등이 발생할 수 있죠.
이럴 때는 다음과 같은 방식으로 재시도하는 것이 좋습니다:
지수 백오프: 요청이 실패할 때마다 점점 길어지는 시간 간격으로 재시도해요.
지터: 일정 범위 내에서 랜덤한 지연 시간을 추가하면, 여러 요청이 한꺼번에 몰리는 걸 방지할 수 있어요.
멱등성 키를 함께 사용하면, 요청이 여러 번 전송되어도 서버에서는 한 번만 처리하게 만들 수 있어요.
멱등성 보장
네트워크 문제처럼 명확한 이유 없이 요청이 실패할 수 있기 때문에, 멱등성은 매우 중요해요.
멱등성을 지원하는 API는 동일한 요청을 여러 번 보내더라도 한 번만 처리되므로, 시스템의 안전성과 신뢰성을 높일 수 있어요.
Mori에서 멱등성을 보장하는 주요 API는 다음과 같아요:
POST /api/v2/orders
(학습 방지 적용 주문 생성, S3 이미지 업로드)
POST /api/v2/orders/with-urls
(학습 방지 적용 주문 생성, 외부 퍼블릭 이미지 URLs)
POST /api/v2/orders/confirm
(학습 방지 적용 주문 확인)
예를 들어, 학습 방지 적용 주문 도중 네트워크 오류가 발생했다면, 같은 멱등성 키를 사용해 다시 요청하더라도 한 번만 처리돼요.
멱등성 키는 UUID를 쓰는것을 권장해요. 실제로 Biz서비스에서도 UUID v4를 통해 멱등성 키를 관리하고 있어요.
멱등성 키는 성공적으로 사용된 시점부터 {n}년간 유효하며, 기간이 지나면 재사용될 수 있어요.
타임아웃
API 요청에는 기본적으로 30초의 타임아웃이 적용돼요.
고객사 앱에서도 동일한 타임아웃 값을 설정해두면, 실패 시 빠르게 재요청을 보낼 수 있어서 더 안정적인 처리 흐름을 만들 수 있어요.
서버 응답 형식
API 요청에는 기본적으로 30초의 타임아웃이 적용돼요.
고객사 앱에서도 동일한 타임아웃 값을 설정해두면, 실패 시 빠르게 재요청을 보낼 수 있어서 더 안정적인 처리 흐름을 만들 수 있어요.
성공 응답 O
{
"success": true,
"message": "some message",
"data": { /* 필요한 경우 응답 데이터 포함 */ },
"meta": { /* 필요한 경우 메타 정보 포함 */ }
}
실패 응답 X
{
"success": false,
"message": "some message",
"code": "some code",
"errors": {
"message": "자세한 설명 (optional)",
"propertyName": "누락된 필드 명 (optional)"
}
}
웹훅
Mori에서는 주요 리소스 상태 변경이 발생했을 때, 해당 내용을 고객사의 앱 또는 서비스로 알려주는 웹훅 기능을 제공해요.
대표적인 이벤트 예시는 다음과 같아요:
ORDER.PROCESSED
: 주문이 처리되었을 때 발생
이벤트가 발생하면, 사전에 등록된 웹훅 URL로 HTTP POST 요청이 전송돼요. 이를 통해 고객사 시스템에서 후속 처리를 자동으로 수행할 수 있어요.
연동 안내
/
연동 기본 정보
연동 기본 정보
MORI API를 통해 Anti-AI 필터를 적용해보세요.
앱 인증
고객사의 애플리케이션이 MORI API에 접근하려면, 반드시 액세스 토큰을 사용한 인증이 필요해요.
일부 API를 호출할 때는 이 액세스 토큰이 자격 증명(Credential) 역할을 하며, 서버로 전송되어야 합니다.
액세스 토큰을 발급받는 온보딩 절차는 아래 이미지에서 확인할 수 있어요:
API 요청 재시도
API 요청은 다양한 이유로 실패할 수 있어요. 예를 들어, 네트워크 오류, 요청 속도 제한, 서비스 지연 등이 발생할 수 있죠.
이럴 때는 다음과 같은 방식으로 재시도하는 것이 좋습니다:
지수 백오프: 요청이 실패할 때마다 점점 길어지는 시간 간격으로 재시도해요.
지터: 일정 범위 내에서 랜덤한 지연 시간을 추가하면, 여러 요청이 한꺼번에 몰리는 걸 방지할 수 있어요.
멱등성 키를 함께 사용하면, 요청이 여러 번 전송되어도 서버에서는 한 번만 처리하게 만들 수 있어요.
멱등성 보장
네트워크 문제처럼 명확한 이유 없이 요청이 실패할 수 있기 때문에, 멱등성은 매우 중요해요.
멱등성을 지원하는 API는 동일한 요청을 여러 번 보내더라도 한 번만 처리되므로, 시스템의 안전성과 신뢰성을 높일 수 있어요.
Mori에서 멱등성을 보장하는 주요 API는 다음과 같아요:
POST /api/v2/orders
(학습 방지 적용 주문 생성, S3 이미지 업로드)
POST /api/v2/orders/with-urls
(학습 방지 적용 주문 생성, 외부 퍼블릭 이미지 URLs)
POST /api/v2/orders/confirm
(학습 방지 적용 주문 확인)
예를 들어, 학습 방지 적용 주문 도중 네트워크 오류가 발생했다면, 같은 멱등성 키를 사용해 다시 요청하더라도 한 번만 처리돼요.
멱등성 키는 UUID를 쓰는것을 권장해요. 실제로 Biz서비스에서도 UUID v4를 통해 멱등성 키를 관리하고 있어요.
멱등성 키는 성공적으로 사용된 시점부터 {n}년간 유효하며, 기간이 지나면 재사용될 수 있어요.
타임아웃
API 요청에는 기본적으로 30초의 타임아웃이 적용돼요.
고객사 앱에서도 동일한 타임아웃 값을 설정해두면, 실패 시 빠르게 재요청을 보낼 수 있어서 더 안정적인 처리 흐름을 만들 수 있어요.
서버 응답 형식
API 요청에는 기본적으로 30초의 타임아웃이 적용돼요.
고객사 앱에서도 동일한 타임아웃 값을 설정해두면, 실패 시 빠르게 재요청을 보낼 수 있어서 더 안정적인 처리 흐름을 만들 수 있어요.
성공 응답 O
{
"success": true,
"message": "some message",
"data": { /* 필요한 경우 응답 데이터 포함 */ },
"meta": { /* 필요한 경우 메타 정보 포함 */ }
}
실패 응답 X
{
"success": false,
"message": "some message",
"code": "some code",
"errors": {
"message": "자세한 설명 (optional)",
"propertyName": "누락된 필드 명 (optional)"
}
}
웹훅
Mori에서는 주요 리소스 상태 변경이 발생했을 때, 해당 내용을 고객사의 앱 또는 서비스로 알려주는 웹훅 기능을 제공해요.
대표적인 이벤트 예시는 다음과 같아요:
ORDER.PROCESSED
: 주문이 처리되었을 때 발생
이벤트가 발생하면, 사전에 등록된 웹훅 URL로 HTTP POST 요청이 전송돼요. 이를 통해 고객사 시스템에서 후속 처리를 자동으로 수행할 수 있어요.
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