진단 순서
1
수집 응답을 본다
POST /v1/events나 POST /v1/event-batches의 HTTP 상태와 응답 본문의 code를 확인합니다. 단건이 200이 아니거나 배치 결과의 원소가 rejected면 그 이벤트는 저장되지 않았습니다. 배치 요청 자체가 400이면 그 요청의 이벤트는 하나도 저장되지 않았습니다. 아래 ‘수집 요청이 거절됐다’ 표를 봅니다.2
업무 환경을 맞춘다
콘솔 화면 위 ‘업무 환경’이 API 키를 발급한 환경과 같은지 확인합니다. 로그인하면 ‘기존 데이터’로 열리므로, 테스트 환경 키로 보냈다면 ‘테스트 환경’으로 바꿔야 보입니다. 자세한 내용은 업무 환경을 보세요.
3
저장됐는지 본다
‘수집 로그’ 화면에서 전송 ID로 찾거나
GET /v1/events/lookup?transaction_id=값을 부릅니다. 없으면 ‘수집 거절’ 화면을 봅니다.4
사용량으로 집계됐는지 본다
‘사용량’ 화면의 ‘수집 확인과 정정’에서 청구에서 빠지는 이벤트 건수를 보고, ‘이벤트 매핑 진단’에서 이벤트별 원인을 봅니다.
5
금액이 붙었는지 본다
‘청구 검토’ 화면이나
GET /v1/invoices/draft?month=YYYY-MM에서 라인과 단가 없는 사용량을 봅니다.6
이미 확정됐는지 본다
고객이 청구 예정액에서 사라졌으면 ‘확정 인보이스’ 화면이나
GET /v1/invoices를 봅니다.증상별 원인과 조치
수집 요청이 거절됐다
배치는 HTTP 상태가 200이어도 원소마다 결과가 다릅니다. 원소별 결과를 읽는 방법과 다시 보낼 것과 멈출 것은 사용량 이벤트 보내기와 재전송 설계를 보세요. 영구 거절 code는 다시 보내지 마세요.
저장됐는데 보이지 않는다
사용량이 0이거나 적다
사용량은 있는데 금액이 없거나 적다
지난달이나 확정한 달의 이벤트가 청구되지 않았다
놓치기 쉬운 것
'수집 거절'의 조회 월은 이벤트의 달이 아니다
'수집 거절'의 조회 월은 이벤트의 달이 아니다
‘수집 거절’ 화면의 ‘거절 기록 월’과
GET /v1/event-rejections/search의 month는 거절을 기록한 달입니다. 10월 31일에 발생한 이벤트를 11월 1일에 보내 거절됐다면 11월에서 찾습니다. 화면에 나오는 ‘최초 거절 기록’ 시각 전의 거절은 기록되어 있지 않습니다.'수집 거절'에는 이벤트 원문이 없다
'수집 거절'에는 이벤트 원문이 없다
수집 거절 기록에는 전송 ID, 요청에 담긴 고객 ID, 이벤트 유형, 발생 시각, 거절 사유, 확인할 항목, 배치 행, 요청 ID, 거절 기록 시각만 남습니다. 원본 속성과 오류 원문은 남지 않습니다. 검색어는 전송 ID와 이벤트 유형만 찾고, ‘요청의 고객 ID’는 등록되지 않은 고객 ID로도 찾을 수 있습니다. 다시 보내려면 원문을 연동 쪽에 보관해 두어야 합니다.
진단 검색의 페이지 번호는 0부터 센다
진단 검색의 페이지 번호는 0부터 센다
GET /v1/event-rejections/search와 GET /v1/event-issues/search의 page는 0부터 세고, 고객이나 사용량 같은 자원의 /search는 1부터 셉니다. 자원별 규칙은 서버 조회와 CSV 내보내기를 보세요.'이벤트 매핑 진단'은 지금의 정의로 다시 계산한다
'이벤트 매핑 진단'은 지금의 정의로 다시 계산한다
‘이벤트 매핑 진단’은 조회할 때의 미터 정의와 단가로 저장된 이벤트를 다시 진단합니다. 단가를 등록하면 그 조합의 ‘적용 단가 없음’ 행은 사라집니다. 이미 확정한 달의 행에는 “인보이스를 확정한 달이라 단가를 등록해도 이 달 청구에는 반영되지 않습니다” 안내가 붙습니다.
마감 뒤에 받은 이벤트를 세는 진단은 없다
마감 뒤에 받은 이벤트를 세는 진단은 없다
‘이벤트 매핑 진단’과 청구 제외 집계(
GET /v1/unbilled-events)는 발생 시각으로만 대상을 고르고 수신 시각은 보지 않습니다. 그래서 집계 마감 뒤에 받아 청구에서 빠진 지난달 이벤트를 따로 세는 항목이 없습니다. GET /v1/events?month=YYYY-MM&sort=received_at&order=desc로 수신 시각이 늦은 이벤트부터 보거나, 이벤트 CSV의 received_at 열로 확인하세요.수집 요청은 감사 기록에 나오지 않는다
수집 요청은 감사 기록에 나오지 않는다
이벤트 수집 요청은 감사 기록에 나오지 않으니 저장된 이벤트와 수집 거절 기록의
request_id, transaction_id로 찾습니다. ‘수집 거절’과 ‘이벤트 매핑 진단’ 화면은 감사 기록에서 확인하라고 안내하지만 수집 요청은 감사 기록에 없습니다. 자세한 내용은 오류 응답과 X-Request-ID를 보세요.malformed_request_body나 단건 validation_error처럼 저장도 거절 기록도 되지 않는 오류는 응답 본문과 응답 헤더 X-Request-ID를 연동 쪽 로그에 남겨 두어야 나중에 찾을 수 있습니다.미리 통보 받기
청구에서 빠지는 사용량이 있으면 웹훅unbilled_usage_detected로 매일 통보를 받을 수 있습니다. 보내는 조건과 본문은 웹훅 이벤트 유형과 data를 보세요. 예약 작업 시각은 시간 규칙에 모았습니다.
그래도 원인을 모르겠다면
문의와 승인 요청 방법은 소개 페이지의 문의 절을 보세요. 문의할 때는 요청한 시각, 응답의code, 응답 헤더 X-Request-ID, 이벤트의 transaction_id를 함께 적어 주세요. API 키와 고객 정보는 적지 마세요.
보낸 데이터 확인하기
저장, 사용량, 청구 예정액 순서로 확인합니다.
재전송 설계
다시 보낼 오류와 멈출 오류를 나눕니다.
서버 조회와 CSV 내보내기
한 달 치 이벤트를 내려받아 자기 기록과 맞춥니다.
시간 규칙
35일, 집계 마감, 청구 월의 기준을 봅니다.