Skip to main content
이 페이지에서는 문맥 타겟팅 API의 오류 응답, 일괄 요청의 결과를 알리는 방식, 안전하게 재시도하는 방법, 요청에 적용되는 한도를 설명합니다.

오류 응답

실패한 요청은 HTTP 오류 상태와 함께 아래 형식 중 하나의 JSON 본문을 반환합니다. 오류는 message 문구가 아니라 HTTP 상태와 errorCode로 구분해 처리하세요.

검증 오류

요청이 처리되기 전에 거부된 경우입니다. 필드가 빠졌거나 잘못된 경우, 이름이나 컨텍스트 ID가 규칙에 맞지 않는 경우, 요청에 허용되지 않는 필드(예: 생성 요청의 _id)가 있는 경우, 요청당 한도를 넘은 경우가 여기에 해당합니다. 일괄 요청이라도 요청의 어떤 내용도 적용되지 않습니다. message는 발견된 문제를 모두 나열한 배열입니다.
경로의 ID가 올바른 ULID가 아니거나 본문이 올바른 JSON이 아니면 message는 문자열 하나입니다.

비즈니스 오류

요청 형식은 올바르지만 서버가 처리할 수 없는 경우입니다. 예를 들어 이름이 이미 사용 중이거나 타겟팅이 없는 경우입니다. 다른 문맥 타겟팅이 이미 쓰고 있는 이름으로 타겟팅을 생성하면 다음과 같이 응답합니다.
단건 엔드포인트는 항목의 오류를 그대로 응답으로 반환합니다. 단, 예기치 않은 오류로 항목이 실패하면 대신 502를 반환합니다. 일괄 작업 엔드포인트는 항목별 오류를 results에 담아 반환합니다. 일괄 작업 응답을 참고하세요.

인증과 권한 오류

401은 x-api-key 헤더가 없거나, 키가 유효하지 않거나 폐기된 경우입니다. 403은 엔드포인트에 필요한 권한(scope)이 키에 없는 경우입니다.

요청 본문 크기 초과

413은 요청 본문이 8 MB보다 큰 경우입니다. 아무것도 적용되지 않습니다.

서버 오류

502는 일시적인 서버 문제로 요청을 완료하지 못한 경우이고, 500은 예기치 않은 서버 오류입니다. 두 경우 모두 요청이 적용됐을 수도 있고 적용되지 않았을 수도 있습니다. message 문구는 달라질 수 있습니다. 재시도와 중복 요청을 참고하세요.

오류 코드

상태별 오류

다음 오류에는 errorCode가 없습니다.

코드별 오류

TARGETING_CATEGORY_NOT_SUPPORTED는 다음 경우에 발생합니다.
  • 옵션 그룹에 하위 옵션도 자체 컨텍스트 ID도 없는 경우
  • type: "atomic"과 함께 children을 보내거나, 일반 옵션에 exposeChildren을 보낸 경우
  • 옵션을 추가할 때 parent를 type: "collection", children, exposeChildren 중 하나와 함께 보낸 경우
  • parent가 최상위 옵션 그룹이 아닌 옵션을 가리키는 경우
  • 수정 요청에서 옵션 그룹에 parent를 보낸 경우. 옵션 그룹은 옮길 수 없습니다.
  • 이동, 분리, 삭제로 자체 컨텍스트 ID가 없는 옵션 그룹의 마지막 하위 옵션이 빠지게 되는 경우
  • 수정으로 하위 옵션이 없는 옵션 그룹의 컨텍스트 ID가 모두 삭제되는 경우
  • 옵션 목록 조회의 parent 쿼리 파라미터가 일반 옵션을 가리키는 경우
  • 옵션 그룹 안에 다른 옵션 그룹이 들어 있는 경우처럼, API로 변경할 수 없는 형태로 저장된 옵션인 경우

detail 필드


일괄 작업 응답

POST /context-targeting/bulk/create, POST /context-targeting/category/bulk/update 같은 일괄 작업 엔드포인트는 항목마다 결과를 반환합니다.

응답 필드

응답 상태

일괄 요청이 처리되면 항목 일부나 전체가 실패해도 200을 반환합니다. failed나 각 항목의 success를 확인하세요. 다음 경우에는 요청 전체가 results 없이 실패하며, 요청의 어떤 내용도 적용되지 않습니다.
  • 400 검증 오류. 예를 들어 항목이 너무 많거나, 컨텍스트 ID가 모두 합쳐 10,000개를 넘거나, 옵션 일괄 수정에 같은 _id가 두 번 들어 있는 경우입니다.
  • 옵션 일괄 삭제의 400 TARGETING_CATEGORY_TREE_ITEMS_LIMIT_EXCEEDED
  • 401, 403, 413
  • 404 PROJECT_NOT_FOUND
  • 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS
500이나 502 응답에도 results가 없지만, 이때는 요청이 적용됐을 수도 있고 적용되지 않았을 수도 있습니다.

항목 적용 방식

  • 옵션 일괄 수정은 항목을 동시에 적용하지만, results는 요청 순서를 그대로 유지합니다. 한 옵션의 변경 내용은 모두 한 항목에 담으세요. 같은 _id가 두 번 들어 있으면 요청 전체가 거부됩니다.
  • 이름 변경·수정 요청에서는 앞 항목이 이름을 바꾸면서 비운 이름을 뒤 항목이 쓸 수 있습니다. 앞 항목이 실패하면 뒤 항목은 이름 중복 오류로 실패합니다.

예시

첫 번째 항목은 Sports에 컨텍스트 ID를 추가합니다. 두 번째 항목은 Tech의 이름을 이미 사용 중인 Sports로 바꾸려고 합니다.
응답 상태는 200입니다.

동시 쓰기

한 프로젝트의 API 쓰기 요청은 한 번에 하나씩 처리됩니다. 프로젝트의 어떤 API 키로 보냈든, 단건과 일괄을 가리지 않고 문맥 타겟팅 API의 모든 POST, PATCH, DELETE 요청이 여기에 해당합니다. GET 요청은 영향을 받지 않으며, 서로 다른 프로젝트의 쓰기 요청은 서로를 기다리지 않습니다. 프로젝트의 다른 쓰기 요청이 처리되는 중에 쓰기 요청이 도착하면, 서버는 앞 요청이 끝나기를 잠시 기다립니다. 그래도 끝나지 않으면 요청은 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS로 실패하며, 요청의 어떤 내용도 적용되지 않습니다. 일괄 요청은 results 없이 전체가 실패합니다.
이 오류는 다음과 같이 처리하세요.
  1. detail.retryAfterMs밀리초만큼 기다립니다. 값은 0~2,000 사이입니다.
  2. 같은 요청을 다시 보냅니다. 다시 409를 받으면 이 과정을 반복합니다.
한 프로젝트의 쓰기 요청은 순서대로 보내세요. 요청 하나의 응답을 받은 뒤에 다음 요청을 보내면 됩니다. 여러 프로세스나 워커가 같은 프로젝트에 쓴다면, 각각 409를 받았을 때 재시도해야 합니다.
드물게, 처리가 유난히 오래 걸리는 요청의 차례를 다른 요청이 넘겨받을 수 있습니다. 그러면 처음 요청이 아직 적용하지 못한 항목은 results에서 같은 409로 실패하며, 단건 엔드포인트에서는 이 오류가 응답으로 반환됩니다. 이 오류를 받은 항목은 적용되지 않았으므로 그 항목만 다시 보내세요.

재시도와 중복 요청

요청이 타임아웃되거나 502 등 5xx 상태를 반환하면 요청이 적용됐는지 알 수 없습니다. 서버가 아직 원래 요청을 처리하고 있을 수도 있습니다. 잠시 기다린 뒤 같은 요청을 다시 보내세요. 원래 요청이 아직 처리 중이면 다시 보낸 요청은 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS로 실패합니다. 이때는 기다렸다가 다시 보내세요. 이미 성공한 요청을 다시 보냈을 때의 결과는 작업에 따라 다릅니다.

생성 요청을 다시 보낼 때

ID는 항상 서버가 생성하며, 생성 요청에 _id를 넣으면 400으로 실패합니다. 이미 성공한 생성 요청을 다시 보냈다면, 항목을 다시 만들지 말고 409 응답에 있는 ID를 사용하세요.
  • 타겟팅: 409 TARGETING_NAME_DUPLICATE. detail.existingId가 그 타겟팅의 ID입니다. 옵션의 ID를 확인하려면 타겟팅 조회를 참고하세요.
  • 옵션: 409 TARGETING_CATEGORY_NAME_DUPLICATE. detail.existingIds에 그 이름을 쓰는 옵션의 ID가 들어 있습니다.
  • 일괄 생성·추가 요청에서는 원래 요청이 만든 항목만 이렇게 실패합니다. 나머지 항목은 평소대로 처리됩니다.
detail.existingId는 기존 타겟팅이 문맥 타겟팅일 때만 포함됩니다. 오디언스 타겟팅이 그 이름을 쓰고 있다면 다른 이름을 고르세요. 같은 요청 안에서 이름이 겹치면 대신 detail.duplicateOfIndex가 반환됩니다. 이때는 요청을 고치세요. 한 프로젝트의 API 쓰기 요청은 한 번에 하나씩 처리되므로, 똑같은 생성 요청 두 개를 동시에 보내도 둘 다 생성되지는 않습니다. 나중에 처리되는 요청은 이름 중복 오류나 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS로 실패합니다.

500이나 502를 받은 경우

  • 생성·추가·삭제 일괄 요청의 results에 500 UNCATCHED가 있는 경우: 요청의 어떤 항목도 적용되지 않았습니다. 같은 요청을 다시 보내세요.
  • 이름 변경·수정 일괄 요청의 results에 500 UNCATCHED가 있는 경우: 그 항목이 실패한 것입니다. 그 항목을 다시 보내세요.
  • 500이나 502 응답을 받은 경우: 요청이 적용됐을 수도 있고 적용되지 않았을 수도 있습니다. 같은 요청을 다시 보내고, 결과는 위 표에 따라 처리하세요.
add와 remove를 함께 보낸 옵션 수정이 실패하면 add는 이미 적용됐을 수 있습니다. 같은 수정 요청을 다시 보내도 안전합니다.

한도

  • 저장된 데이터에 대한 한도(옵션당, 프로젝트당, 타겟팅당, 광고 상품당)는 변경으로 양이 늘어날 때만 확인합니다. 컨텍스트 ID 삭제처럼 양을 줄이는 변경은 데이터가 이미 한도를 넘은 상태여도 막히지 않습니다.
  • 요청 하나에 담을 수 있는 양보다 많이 올리려면 이 한도 안에서 요청을 나눠 하나씩 차례로 보내세요. 예를 들어 옵션 수만 개는 항목 5,000개 이하의 옵션 일괄 추가 요청으로 나눠 추가합니다.
  • 컨텍스트 ID가 10,000개를 넘는 옵션의 컨텍스트 ID를 교체하려면 컨텍스트 ID 갱신 방법을 참고하세요.
  • 요청 본문을 작게 유지하려면 한글 이름이나 컨텍스트 ID 같은 비ASCII 문자를 UTF-8 그대로 보내세요.

이름 규칙

타겟팅 이름과 옵션 이름(옵션 그룹과 하위 옵션 포함)에는 다음 규칙이 적용됩니다.
  • 일본어나 중국어 문자, _, ., 괄호 등 그 밖의 문자는 허용되지 않습니다.
  • 요청 하나 안에서 겹치는 이름도 중복입니다. detail 필드의 duplicateOfIndex를 참고하세요.
  • 현재 이름으로 이름을 변경해도 오류가 아닙니다.
  • 서로 다른 타겟팅에 있는 옵션은 이름이 같아도 됩니다.

콘솔과 함께 쓸 때

  • 같은 데이터: 콘솔과 API는 같은 문맥 타겟팅을 관리합니다. API로 만든 타겟팅과 옵션은 콘솔에 표시되고, 콘솔에서 만든 타겟팅과 옵션도 API로 조회됩니다.
  • 문맥 타겟팅만 지원: 오디언스 타겟팅에 대한 요청은 404 TARGETING_NOT_FOUND로, 그 옵션에 대한 요청은 404 TARGETING_CATEGORY_NOT_FOUND로 실패합니다. 단, 이름이 고유한지 확인할 때는 오디언스 타겟팅의 이름도 포함되므로, 같은 이름으로 문맥 타겟팅을 만들면 detail.existingId 없이 409 TARGETING_NAME_DUPLICATE로 실패합니다.
  • 콘솔 편집은 순차 처리에서 제외: 한 번에 하나씩 처리하는 방식은 API 쓰기 요청에만 적용됩니다. 콘솔 편집은 API 쓰기를 기다리지 않고 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS를 일으키지도 않으며, API 쓰기도 콘솔 편집을 기다리지 않습니다.
  • 동시 변경 시 충돌 가능: 콘솔과 API가 같은 타겟팅을 동시에 변경하면 나중에 저장된 변경이 앞선 변경을 덮어쓸 수 있고, 두 타겟팅이나 두 옵션의 이름이 같아질 수 있습니다. API 연동이 타겟팅을 변경하는 동안에는 콘솔에서 그 타겟팅을 편집하지 마세요. 콘솔에서 변경됐을 수 있다면 쓰기 전에 타겟팅을 다시 조회하세요.
  • 중복된 이름: 두 타겟팅이나 두 옵션의 이름이 같아졌다면 그중 하나의 이름을 바꾸거나 하나를 삭제하세요. 옵션을 삭제하기 전에는 광고 상품과 캠페인에 미치는 영향을 확인하세요.
  • 광고 상품 설정: 광고 상품에서 어떤 옵션을 필수 포함 또는 필수 제외로 설정할지는 콘솔에서 바꾸세요. 타겟팅 판매하기를 참고하세요.