# 채널 API·기존 자동수집 확인 근거

API 존재, 고객 기존 운영, 수령한 실데이터, 고객 앱 권한과 ERP 쓰기 권한을 별도로 판단한다. 이번 조사는 전사록 중심이며 직접 API 호출은 하지 않았다.

기존 현업 제출본을 먼저 적재하는 방향과 기존 API/Make/BigQuery 재사용은 병행한다. 신규 API 구축이 대시보드의 선행조건도, 모든 API 작업이 후순위라는 뜻도 아니다. 기계가독 정본은 [채널 현황 JSON](../../channel-data-status.json)의 `api_sources`다.

## 글로벌 Amazon

- API 존재: 공식 SP-API의 주문·보고서 API 존재 확인
- 고객 현행: 글로벌팀은 Make로 매출 데이터를 연동 중이라고 설명
- 확보/대상 범위: 미국/기타 국가 판매 지표. 주문·재고·광고 전체 수집 완료라는 뜻은 아님
- 한계: 광고 미연계 설명. 국가·계정·scope·성공 로그·FBA 상세 입고예정 범위 미검증
- 우선 재사용: 기존 Make 시나리오와 후단 시트를 먼저 받아 재사용
- 파일 보완: 현재 보고용 시트를 먼저 적재 가능; API 재개발을 선행조건으로 두지 않음

[원본 L91–L92](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:11:02 Speaker 5

> 메이크 이용해가지고 지금 아마존하고 그 다음에 쇼피파이는 데이터를 그냥 다 갖고 오고 있고

[원본 L167–L168](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:23:01 Speaker 6

> 그 해당 매출 부분만 지금은 값 있게 메이크 그걸 이용해서 지금은 연동하고 있는 중이고.

공식 제품 자료: [Amazon SP-API 개발자 안내](https://developer-docs.amazon.com/sp-api/docs/onboarding-overview) — 주문 처리·재고/주문 보고서 API 제공. 고객 앱 승인·권한은 별도.

후속 확인: Make 시나리오/계정/스케줄/필드 확인 / 기존 적재 누락·재실행과 마감 정산 데이터의 차이 확인

## 일본 Amazon

- API 존재: 공식 SP-API 존재와 일본 담당의 API 가능 인식
- 고객 현행: 일본 담당은 API를 아직 시도하지 않았다고 설명. 글로벌 Make 운영과 구별
- 확보/대상 범위: 수령 자료는 BusinessReport 스냅샷과 데일리 시작품 관련 시트; FBA 시뮬레이션 설명
- 한계: 일본 계정 API 권한/운영 로그·정산/재고 endpoint 미확인
- 우선 재사용: 글로벌의 기존 수집 방식을 일본 계정에 재사용할 수 있는지 먼저 확인
- 파일 보완: 기존 일별 판매/FBA 보충 시뮬레이션 파일로 우선 적재

[원본 L335–L336](../../../../03_실행관리/회의록/2026-09-09_데이터통합·관리전략_일본채널·Amazon/01_원본전사록.txt) · 00:42:08 Speaker 7

> 아마존 API 되는 걸로 알고 있는데 시도는 못 해봤어요.

공식 제품 자료: [Amazon SP-API 개발자 안내](https://developer-docs.amazon.com/sp-api/docs/onboarding-overview) — 주문 처리·재고/주문 보고서 API 제공. 고객 앱 승인·권한은 별도.

후속 확인: 일본 계정과 글로벌 앱의 사용권한/계정 범위 확인 / 판매통계와 주문·배송·FBA 재고별 보고서 선정

## 일본 Qoo10

- API 존재: 현업이 API 값이 있다고 직접 설명
- 고객 현행: 연결이 한 곳으로 제한되고 현재 물류와 연결됐다는 설명
- 확보/대상 범위: 현재 결제일 주문 반출·장바구니 중복 제거·복합 코드 분해·판매 수량 가공. API 실제 응답은 미수령
- 한계: 한 곳 제한은 고객 설명이며 현재 계약/정책 검증 아님. 글로비스의 총액/품목/주문키 재사용 가능성 미확정
- 우선 재사용: 현재 물류 연결을 유지하고 조회권한 추가 또는 기존 물류/수집 후단 재사용 검토
- 파일 보완: 일간 가공 판매추이와 월 ERP 수주등록 직전 파일을 우선 수집

[원본 L17–L18](../../../../03_실행관리/회의록/2026-09-09_데이터통합·관리전략_일본채널·Amazon/01_원본전사록.txt) · 00:02:47 Speaker 4

> API 값이 있긴 있는데.

[원본 L19–L20](../../../../03_실행관리/회의록/2026-09-09_데이터통합·관리전략_일본채널·Amazon/01_원본전사록.txt) · 00:03:00 Speaker 4

> 그게 한 군데랑만 연결된 거 아시죠?

[원본 L19–L20](../../../../03_실행관리/회의록/2026-09-09_데이터통합·관리전략_일본채널·Amazon/01_원본전사록.txt) · 00:03:00 Speaker 4

> 그게 지금 물류랑 물려있어서.

후속 확인: API key의 발급 주체·현재 연결·읽기 허용 범위 확인 / Qoo10와 글로비스 주문키/상세 품목/금액을 표본 비교 / 장바구니 수와 고유 고객 수 구별, 세트/증정 효력기간 규칙 확보

## TikTok Shop 기본 주문·광고

- API 존재: 기본 주문·광고 수집이 가능하다는 현업 설명과 수령 VIEW/추출 표본 존재
- 고객 현행: Make의 GMV Max 미지원 설명 뒤 별도 전달 시트에서 해결했다는 설명
- 확보/대상 범위: 샵 주문/ERP 구성품목, 일반 광고·GMV Max·가격 스냅샷 표본
- 한계: 모든 API/전체 이력/모든 컬럼 허용을 뜻하지 않음. 상품 분석 화면 6개월 제한은 해당 화면 설명
- 우선 재사용: 현재 TikTok 수집 코드·BigQuery VIEW·시트와 광고 경로를 먼저 재사용
- 파일 보완: 기존 피벗·추출 결과를 1차 적재; 상세 원천 범위를 후속 확장

[원본 L1–L2](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:00:00 Speaker 1

> 그거 말고는 웬만하면 매출이랑 광고 기본적인 데이터들은 다 가지고 올 수 있는

[원본 L113–L114](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:15:04 Speaker 1

> 그거를 지금 해결해둔 게 그 받으신 엑셀 데이터 기준의 시트입니다.

[원본 L105–L106](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:13:48 Speaker 1

> 6 개월 기간까지 밖에 확인이 안 되더라고요

후속 확인: 기본 주문/일반 광고/GMV Max/가격 스케줄과 소유자 확인 / 수령 500행 VIEW 표본과 전체 데이터 구분 / 6개월 화면 제한과 주문 원천 보존범위 별도 검증

## TikTok Shop Affiliate·크리에이터 귀속

- API 존재: 일반 클라이언트 API 제한이라는 현업 설명; 화자는 최신 정책 재확인 전이라고 유보
- 고객 현행: 샵 주문과 별도의 Affiliate 주문을 수동 반출해 Order ID로 결합
- 확보/대상 범위: 크리에이터 주문/매출·환불과 기본 주문의 매칭 후보
- 한계: Affiliate 직접 API의 현재 권한·최신 정책은 미확인. 일반 노출 시딩은 직접 주문 귀속 데이터가 아님
- 우선 재사용: 기존 수동 가공 결과와 주문 매칭 규칙을 재사용하고 API 범위 재확인
- 파일 보완: Affiliate Center 등 실제 반출 파일과 Order ID를 연결; 화면명/기간/반품 상태 확인

[원본 L25–L26](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:03:38 Speaker 1

> 그걸 지금 못 받는 상태인 거거든요.

[원본 L59–L60](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:07:33 Speaker 1

> 나중에 정책이 바뀔 수 있는데 제가 마지막으로 확인한 건 아니에요.

[원본 L129–L130](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:17:44 Speaker 1

> 그걸 오더 ID 기준으로 매칭을 하면 구분이 되는

후속 확인: 고객 권한으로 가능한 Affiliate 범위 공식 확인 / Order ID 조인의 grain·다대다 증폭·환불/취소·기간 검증 / 제출 주기를 협의하고 미수령을 0성과로 표시하지 않음

## 네이버 커머스API

- API 존재: 공식 커머스API에 상품 주문 목록/상세/변경 내역 조회 존재
- 고객 현행: 9/8 현업은 네이버와 외부 물류 연동 및 API 발급 미실행 정황을 설명. 대화가 품고/네이버를 오가므로 어느 키인지 확정하지 않음
- 확보/대상 범위: 품고 주문·배송 파일은 수령. 네이버 커머스API 직접 응답·고객 앱 권한은 미확인
- 한계: 네이버 커머스API 조회, 품고 재고/API, ERP 쓰기는 서로 다른 경로
- 우선 재사용: 기존 네이버↔물류 연동과 앱 등록 상태부터 확인
- 파일 보완: 현재 영업 가공파일/품고 주문 결과로 시작; API 가능 범위는 병행 확인

[원본 L217–L218](../../../../03_실행관리/회의록/2026-09-08_1402_네이버·컬리·비마트_매출·재고·상품코드/01_원본전사록.txt) · 00:28:12 Speaker 4

> 네이버랑 연동이 되어 있기 때문에

[원본 L219–L220](../../../../03_실행관리/회의록/2026-09-08_1402_네이버·컬리·비마트_매출·재고·상품코드/01_원본전사록.txt) · 00:28:20 Speaker 5

> 있어요 봤어요 근데 발급을 안 했네.

공식 제품 자료: [네이버 커머스API 소개](https://apicenter.commerce.naver.com/ko/assets/apidocs/openapi-doc.html) — 사용하려면 가입·앱 등록과 사용 권한·인증 필요.

공식 제품 자료: [네이버 주문 조회 API](https://apicenter.commerce.naver.com/docs/commerce-api/current/%EC%A3%BC%EB%AC%B8-%EC%A1%B0%ED%9A%8C) — 상품 주문 목록/상세/변경 내역 조회. 고객 권한 확인은 별도.

후속 확인: 앱 소유·판매자 권한·발급 상태 확인 / 주문번호/상품주문번호와 품고 키 매핑 확인 / 결제/구매확정/정산일을 구별

## 품고 API

- API 존재: 9/8 API 존재·발급 여부를 논의했으나 공식 사양/견적은 미수령
- 고객 현행: 네이버와 품고 연동 설명. 플랫폼 직접 API 조회 성공은 확인 안 됨
- 확보/대상 범위: 품고 주문/재고/입고/SKU 실제 파일·메뉴 근거 존재
- 한계: 비용 발언은 추정. 네이버 키와 품고 키의 발급주체·조회 범위 구분 필요
- 우선 재사용: 품고 기존 연동·반출을 확인하고 재사용
- 파일 보완: 대시보드에서 ERP용 파일 생성 후 사람이 올리는 차선 논의. ERP 반영 결과 확인 필요

[원본 L215–L216](../../../../03_실행관리/회의록/2026-09-08_1402_네이버·컬리·비마트_매출·재고·상품코드/01_원본전사록.txt) · 00:28:07 Speaker 2

> 근데 풍고는 API 이런게 있어요?

[원본 L219–L220](../../../../03_실행관리/회의록/2026-09-08_1402_네이버·컬리·비마트_매출·재고·상품코드/01_원본전사록.txt) · 00:28:20 Speaker 5

> 있어요 봤어요 근데 발급을 안 했네.

[원본 L233–L234](../../../../03_실행관리/회의록/2026-09-08_1402_네이버·컬리·비마트_매출·재고·상품코드/01_원본전사록.txt) · 00:29:09 Speaker 3

> 이거를 받아서 ERP 로 또 쏘는 건 또 다른 문제라고

후속 확인: API 계약/조회권한·요금·재고 기준시각 확인 / ERP 전송/쓰기 계약·권한과 분리

## Shopify

- API 존재: 글로벌팀은 Make 연계를 운영 중이라고 설명
- 고객 현행: Amazon과 함께 기존 Make 수집
- 확보/대상 범위: 해외 자사몰 판매 후단 시트
- 한계: 고객 앱 scope·상세 컬럼·실행로그 미검증
- 우선 재사용: 기존 Make 시나리오/시트 재사용
- 파일 보완: 기존 제출파일 또는 후단 데이터 우선

[원본 L91–L92](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:11:02 Speaker 5

> 그 다음에 쇼피파이는 데이터를 그냥 다 갖고 오고 있고

후속 확인: 샵/통화/기간·환불/취소 범위·주문키 확인

## YesStyle

- API 존재: API 없음이 확정된 것은 아님. 현재 방식은 BIS/Tableau 파일 반출
- 고객 현행: Tableau에서 파일 두 개 다운로드→시트→Slack 후단 자동화 설명
- 확보/대상 범위: 수령 파일은 기간 미표기 상품 판매 순위/수량 표본
- 한계: 현재 고객 접근권한·일괄 반출/자동조회 허용 범위 미확인
- 우선 재사용: 이미 있는 시트 적재/Slack 가공을 재사용
- 파일 보완: BIS/Tableau 반출파일의 기간·상품키를 보강

[원본 L91–L92](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:11:02 Speaker 5

> 그 BIS 태블로 기반으로 정보가 있어요.

[원본 L193–L194](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:24:21 Speaker 5

> 다운로드 받으면 얘를 엑셀로 스프레드시트에 로우데이터로 적재하는 거죠.

후속 확인: 현재 최종시트·반출 파일2종·날짜 선택·갱신위치 확인

## SNS·Apify 기반 콘텐츠 지표

- API 존재: 전사록에서 수기 및 대량 수집 도구 사용 설명
- 고객 현행: 조회수·좋아요·댓글·공유 등 수기/Apify→시트
- 확보/대상 범위: 콘텐츠 지표; 댓글 원문 수집은 희망 범위 설명
- 한계: 모든 SNS 통합 수집·장기 안정성·직접 매출 귀속 보장 없음
- 우선 재사용: 기존 콘텐츠 목록·수집 도구/후단 시트 확인
- 파일 보완: 운영 중인 가공 리포트 우선

[원본 L97–L98](../../../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/01_원본전사록.txt) · 00:12:42 Speaker 5

> 어피파이 이용해가지고

후속 확인: 콘텐츠ID·게시시각·수집시각·플랫폼별 필드·권한 확인


## 추가 수기메모와 원전 대조

[9/9 수기 원문](../../../../03_실행관리/회의록/2026-09-09_인터뷰통합정리·수기메모/03_수기메모_추가원문_2026-09-09_01.txt)도 함께 확인했다. Qoo10의 `+ / _D / _T`는 메모상 규칙으로 실제 코드맵 검증 전 확정하지 않는다. TikTok 상품 단위 6개월은 전사록상 분석 화면의 조회범위이며 Apify 보존정책으로 연결하지 않는다. 매출 데이터 불가는 크리에이터 귀속 제약과 기본 샵 주문 수집을 구분한다. Amazon 국가·창고수는 메모와 전사록의 차이/발언 변동이 있어 고정하지 않는다.

발급 절차·현재 공식문서 재확인은 [2026-09-21 API 발급·권한 실행 안내](../../../구현준비/API_발급·권한_실행안내_2026-09-21.md)를 참고한다. 기존 현업 설명과 실제 API 권한 확인은 구별한다.