GraphQL 리포팅 API 는 광고주와 퍼블리셔에게 리포트 데이터에 접근할 수 있도록 하는 Tapjoy 플랫폼 입니다. GraphQL 리포트 API 내 마케팅 API를 통한 광고주의 케이스에 대하서는 이 링크를 참조해 주시길 바랍니다. 퍼블리셔의 사용자 케이스는 퍼블리셔 API 항목이 설명된 이 링크에서 확인하실 수 있습니다.
마켓팅 퍼블리셔 API 에 접근하기 위해서는 먼저 API Key 가 필요합니다. Ad 대시보드 사용자의 경우 이 링크에서 key 를 확인할 수 있습니다. https://dashboard.tapjoy.com/reporting/api
LTV 플랫폼 사용자라면 마케팅 API Key 가 필요하며 이는 LTV 플랫폼에서 확인하실 수 있습니다. 이 키는 App -> Settings -> App Settings -> App Info -> API Keys -> Marketing API Key 를 통해 확인하실 수 있습니다.
API 요청은 표준 two-legged OAuth2 를 사용하여 인증합니다. 모든 토큰은 API Key 를 통해 요청되며 이를 통해 받은 토큰은 향후 요청시 인증을 위해 사용합니다.
인증 토큰을 발급받는 방법은 이 링크를 참고해 주시길 바랍니다..
API 는 하나의 엔드포인트만 존재합니다.
https://api.tapjoy.com/graphql
엔드포인트는 어떠한 작업을 요청하더라도 변경되지 않습니다.
인증 토큰 발급이 완료되면 API를 통해 요청할 수 있습니다. API 요청을 위해서는 HTTP POST 로 JSON 형식의 Body 로 요청하셔야 합니다.
예시:
POST /graphql
Host: api.tapjoy.com
Authorization: Bearer <OAuth Token>
{
"query": "query { user { firstName } }"
}
API 사용시 다음 항목의 에러가 나오는 상황이 있을 수 있습니다.
API 가 정상적으로 연동된 것인지 확인하기 위해서는 이들 항목의 에러에 대하여 관린해야할 필요가 있습니다.
각각의 항목에 대해서는 아래의 쿼리를 기준으로 설명할 것입니다.
query {
user {
firstName
lastName
}
}
간혈적으로 복구할 수 없는 서버 / 네트워크 에러가 API 를 통해 발생할 수 있습니다. 이 경우 API를 통해 전달받은 http 상태 코드에 따라 시나리오를 새워 대응할 수 있습니다. 예를 들어 API 에 문제가 생겨 쿼리 실행을 막는다면 HTTP 500 상태 코드를 받아 대응할 수 있습니다.
아 시나리오에서 가장 좋은 대응 방법은 API 호출을 재시도 하는 것입니다.
인증과 관련된 에러는 아래와 같은 이유로 발생합니다.
이 상황이 발생했을 경우 HTTP 200 OK 응답과 함께 아래의 데이터를 받습니다.
{
"errors": [
{
"message": "Authentication could not be verified. Please try again later.",
"code": 403
}
]
}
message
- 에러 관련 설명 메시지code
- HTTP 상태 코드이 시나리오에서 가장 좋은 대응 방법은 새로운 토큰을 발급받고 API를 재시도 하는 것입니다.
모든 쿼리는 구문이 정확한지 여부 및 데이터 스키마를 따르는지 사전에 검증됩니다. 만약 해당 쿼리가 스키마 검증을 통과하지 못할 경우 HTTP 200 OK 응답과 함께 아래 데이터를 받게 됩니다.
{
"errors": [
{
"message": "Field 'user' doesn't exist on type 'Query'",
"locations": [
{
"line": 2,
"column": 3
}
],
"fields": [
"query",
"user"
]
}
]
}
message
- 에러 관련 설명 메시지locations
- 에러 위치fields
- 에러에 따라 영향을 받는 필드이 시나리오에서 가장 좋은 대응방법은 API 문서를 기준으로 쿼리를 테스트하는 것입니다. 온라인 도구.
API 와 관련한 모든 설정을 완료하였더라도 여저히 에러가 발생할 수 있습니다. 예를 들어 여러분이 광고주이고 아래 API 를 통해 AdSet의 최소 비딩 값을 설정한다고 가정해 봅시다.
mutation {
updateAdSet(input: {
id: "00000000-0000-0000-0000-000000000000",
bidding: {amount: 10000}
}) {
adSet {
id
}
}
}
이 시나리오에서는 HTTP 200 OK 응답과 함께 아래 데이터를 받게 됩니다.
{
"data": {
"updateAdSet": null
},
"errors": [
{
"message": "Amount is below the minimum (20000 micros)",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"updateAdSet",
"input",
"bidding",
"amount"
],
"code": 422
}
]
}
message
- 에러 관련 메시지locations
- 에러가 발생한 위치path
- 에러가 발생한 필드 위치code
- HTTP 상태 코드이 시나리오에서 가장 좋은 대응방법은 사용자에게 해당 필드 (경로값)에 대한 메세지를 확인 후 수정하는 것입니다.