Tracking API와 Shipping API: 귀사의 이커머스 스택에는 어느 것이 필요한가요(아니면 둘 다)?
전자상거래 스택에서 배송을 생성하고 배송 라벨을 발행해야 할 때는 배송 API를 사용하세요. 발송 후 배송을 추적하고 운송업체 업데이트를 유용한 운영 정보나 고객용 정보로 전환해야 할 때는 추적 API를 사용하세요. 소프트웨어가 배송 생성과 구매 후 배송 가시성을 모두 관리해야 한다면 두 가지 기능이 모두 필요하지만, 반드시 두 개의 공급업체나 별도의 두 통합을 사용할 필요는 없습니다.
이 결정은 일반적으로 엔지니어링 팀과 협력하는 전자상거래 운영 책임자처럼 주문 처리 아키텍처를 담당하는 사람이 내려야 합니다. 먼저 스토어, 창고 또는 주문 처리 파트너가 이미 처리하는 업무를 파악하세요. 새로운 API를 추가할 때는 이미 정상적으로 작동하는 워크플로를 중복하는 것이 아니라 특정 공백을 해결해야 합니다.
추적 API와 배송 API의 차이점은 무엇인가요?
차이는 제품 범주 사이의 엄격한 경계가 아니라 각 API가 수행하는 업무에 주로 있습니다. 배송 플랫폼에 추적 엔드포인트가 포함될 수도 있고, 추적 서비스가 알림 및 고객용 배송 업데이트 도구를 제공할 수도 있습니다. 제품명에 의존하기보다는 문서화된 엔드포인트와 이벤트 동작을 평가하세요.
| 결정 기준 | 추적 API | 배송 API |
|---|---|---|
| 주요 업무 | 배송 상태와 추적 이벤트를 조회하거나 수신합니다. | 배송을 생성하고 라벨 및 관련 배송 문서를 발급받습니다. |
| 일반적인 입력값 | 운송장 번호, 운송업체 식별자 및 추가로 필요한 배송 세부 정보 | 발송인 및 수취인 정보, 패키지 정보, 서비스 선택 및 해당되는 통관 데이터 |
| 일반적인 출력값 | 배송 상태, 이벤트 이력 및 기타 이용 가능한 배송 정보 | 배송 식별자, 라벨 및 지원되는 문서 |
| 주요 워크플로 | 배송 가시성, 예외 처리 및 구매 후 업데이트 | 창고 발송 및 출고 배송 준비 |
| 가정해서는 안 되는 사항 | 추적 액세스에 라벨 생성이나 운송업체 예약이 포함된다고 가정하지 마세요. | 라벨 생성에 필요한 수준의 추적 정보와 알림 제어 기능이 포함된다고 가정하지 마세요. |
운송업체 문서는 이러한 분리를 잘 보여줍니다. FedEx는 Ship API 문서에서 배송 생성을, 추적 API 문서에서 추적 기능을 설명합니다. 이는 서로 다른 기술적 책임의 예시일 뿐이며, 특정 운송업체를 선택하라는 권고는 아닙니다.
배송 생성은 배송 이동을 관찰하는 것과 다릅니다
배송 생성 요청이 성공했다는 응답은 배송 요청이 처리되었음을 소프트웨어에 알려줍니다. 그러나 운송업체가 실제로 소포를 인수했다는 의미는 아닙니다. 마찬가지로 배송 이력에 이동이 표시되기 전에 운송장 번호가 먼저 존재할 수도 있습니다.
따라서 주문 관리 시스템은 라벨 생성, 창고 인계, 운송업체 인수 및 배송 완료를 구분해야 합니다. 이 모든 단계를 하나의 ‘배송됨’ 이벤트로 처리하면 고객에게 너무 이른 메시지가 전송되고 실제로 창고를 떠나지 않은 소포가 숨겨질 수 있습니다.
현재 병목을 해결하는 기능을 선택하세요
발송이 부족한 부분이라면 배송 API를 선택하세요
자체 애플리케이션이 주문 데이터를 배송으로 변환해야 할 때 배송 API가 적절한 출발점입니다. 예를 들어 창고 팀이 운송업체 포털에 주소를 수동으로 복사하거나, 사용자 지정 주문 관리 시스템에서 라벨을 생성할 수 없는 경우가 있습니다.
통합을 선택하기 전에 실제 발송 워크플로를 정의하세요. 배송 생성만 필요한가요, 아니면 요금 조회, 취소, 픽업 요청, 통관 문서 또는 일일 마감 처리도 필요한가요? 이러한 기능은 별도의 API일 수 있고, 운송업체에 따라 다르거나, 추가 계정 권한이 필요할 수 있습니다. ‘배송 API’라고 표시된 제품에 모든 배송 작업이 포함되어 있다고 가정하지 마세요.
단독 솔루션으로는 적합하지 않은 경우: 라벨 생성은 해결하지만 고객 서비스 팀이 개별 운송업체 웹사이트를 계속 확인해야 하는 통합입니다. 이 통합은 발송 문제를 해결하면서 배송 가시성은 거의 개선하지 못할 수 있습니다.
배송 생성이 이미 작동한다면 추적 API를 선택하세요
창고 관리 시스템, 주문 처리 파트너, 마켓플레이스 또는 기존 배송 통합에서 이미 라벨을 생성하고 있지만 배송 정보가 분산되어 있다면 추적 API가 더 직접적인 선택입니다.
이 경우 라벨 워크플로를 교체하면 핵심 문제를 해결하지 못한 채 마이그레이션 작업만 늘어날 수 있습니다. 대신 상위 시스템에서 생성된 운송장 번호를 주문 관리 시스템, 지원 도구 및 고객 커뮤니케이션에서 사용할 수 있는 가시성 계층에 연결하세요.
이 범주에서 17TRACK Tracking API는 적절한 통합 옵션입니다. 공식 API 문서에서는 푸시 알림을 포함한 운송장 번호 등록 및 추적 데이터 워크플로를 설명합니다. 이러한 워크플로를 필요한 운송업체, 배송 유형 및 애플리케이션 아키텍처와 비교하여 평가하세요. 이는 추적 계층에 관한 고려 사항이며, 해당 서비스가 라벨 생성 통합을 대체한다는 증거는 아닙니다.
단독 솔루션으로는 적합하지 않은 경우: 소프트웨어가 발송을 담당하는 배송을 아직 생성할 방법이 없는데 추적 API를 사용하는 경우입니다. 배송 가시성은 누락된 배송 실행 문제를 해결하지 못합니다.
애플리케이션이 발송과 배송 가시성을 모두 담당한다면 두 기능을 모두 사용하세요
스택에서 라벨을 생성한 다음 배송 진행 상황을 신뢰성 있게 계속 확인해야 한다면 두 기능이 모두 적절합니다. 두 기능은 하나의 플랫폼, 별도의 서비스 또는 운송업체 통합과 추적 계층의 조합으로 제공될 수 있습니다.
배송 및 추적 기능이 문서화된 요구 사항을 불필요한 타협 없이 충족한다면 하나의 통합을 우선 고려하세요. 기존 배송 워크플로를 유지할 가치가 있거나 추적 요구 사항이 해당 워크플로에서 제공하는 기능과 본질적으로 다르다면 별도의 통합을 고려하세요. 별도의 추적 공급업체가 자동으로 더 나은 것은 아닙니다. 추가 통합, 비용 청구 및 운영 책임을 정당화할 수 있어야 합니다.
두 API는 전자상거래 스택에 어떻게 통합되나요?
실용적인 설계에서는 주문, 배송 및 추적 이벤트를 별도의 레코드로 유지합니다. 하나의 주문에서 여러 소포가 생성될 수 있고, 각 소포에는 자체 추적 이력이 있을 수 있습니다. 고객에게 표시되는 주문 상태는 이러한 배송 레코드에서 파생해야 하며, 해당 레코드를 덮어써서는 안 됩니다.
- 주문이 주문 처리 준비 상태가 됩니다. 스토어 또는 주문 관리 시스템이 필요한 주문 처리 데이터를 담당 창고로 전송합니다.
- 배송 워크플로가 배송을 생성합니다. 애플리케이션은 반환된 배송 식별자, 운송장 번호, 운송업체, 서비스 및 라벨 참조 정보를 저장합니다.
- 창고가 인계를 완료합니다. 창고 확인과 운송업체 인수는 서로 구분되는 이벤트로 유지합니다.
- 추적 워크플로가 시작됩니다. 애플리케이션은 선택한 통합에 따라 필요한 방식으로 운송장 번호를 등록하거나 제출합니다.
- 추적 업데이트가 애플리케이션에 도달합니다. 웹훅, 폴링 또는 지원되는 조합을 통해 배송 레코드가 업데이트됩니다.
- 비즈니스 규칙이 다음 단계를 결정합니다. 관련 조건이 충족되면 시스템이 고객에게 표시되는 상태를 업데이트하거나 운영 작업을 생성하거나 메시지를 보냅니다.
예를 들어 외부 주문 처리 창고를 사용하는 판매자는 자체 소프트웨어에서 4~6단계만 필요할 수 있습니다. 배송 생성은 이미 창고가 담당하기 때문입니다. 자체 창고를 운영하는 판매자는 전체 흐름이 필요할 수 있습니다.
각 후속 작업에 하나의 담당 시스템을 지정하세요
두 통합에서 모두 추적 업데이트를 제공한다면 고객 알림과 스토어에 표시되는 배송 상태를 어느 시스템이 관리할지 지정하세요. 그렇지 않으면 고객이 중복 메시지를 받거나 서로 충돌하는 배송 상태를 볼 수 있습니다.
모든 데이터 소스가 이메일을 트리거하도록 허용하지 않으면서 조사를 위해 보조 데이터를 보관할 수 있습니다. 지원 직원이 시스템이 특정 방식으로 배송을 분류한 이유를 이해할 수 있도록 원본 운송업체 이벤트를 내부 상태 매핑과 함께 보존하세요.
기능 라벨이 아니라 운영 적합성을 비교하세요
실제로 사용하는 운송업체와 서비스를 확인하세요
운송업체 지원은 단순한 예 또는 아니오의 문제가 아닙니다. 어떤 서비스가 특정 운송업체의 추적은 지원하면서 해당 운송업체의 라벨 생성은 지원하지 않을 수 있습니다. 라벨 생성은 출발 국가, 운송업체 계정 설정 또는 서비스 이용 자격에 따라 달라질 수도 있습니다.
실제 배송 경로를 기준으로 테스트 목록을 만드세요. 국내 소포, 국제 배송 및 운송 파트너 간 인계를 포함하세요. 각 항목에 필요한 작업이 배송 생성인지, 추적인지 또는 둘 다인지 확인하세요. 광범위한 지원 범위 설명보다 비즈니스가 의존하는 서비스에 대한 성공적인 테스트가 더 유용합니다.
이벤트 의미와 데이터 완전성을 점검하세요
추적의 경우 첫 번째 스캔 전, 배송 예외 발생 중, 배송 시도 실패 후 및 배송 완료 시 어떤 일이 발생하는지 테스트하세요. 타임스탬프에 시간대 정보가 포함되는지, 원래 운송업체 설명을 계속 확인할 수 있는지 점검하세요.
정규화된 상태가 모든 운송업체에서 동일한 데이터를 보장한다고 해석하지 마세요. 예상 배송일, 위치 세부 정보 및 배송 증명 정보는 기반 운송업체와 배송에 따라 달라질 수 있습니다. 이러한 필드가 없을 때 인터페이스가 어떻게 동작할지 결정하세요.
양쪽의 장애 복구를 확인하세요
배송의 경우 배송 생성 중 타임아웃에 특히 주의해야 합니다. 애플리케이션이 응답을 받지 못했더라도 요청이 성공했을 수 있습니다. 무작정 재시도하기 전에 공급업체가 지원하는 중복 방지 및 조정 메커니즘을 확인하세요.
추적의 경우 중복 알림, 지연된 이벤트, 웹훅 전송 실패 및 일시적인 엔드포인트 중단을 테스트하세요. 관련 문서에서 인증, 재시도 동작 및 복구 옵션을 확인하세요. 업데이트를 재생해도 동일한 고객 알림이 다시 전송되지 않도록 이벤트 처리를 설계하세요.
가격 모델을 가정하지 말고 총 운영 비용을 비교하세요
API 요금과 우편 요금 및 운송업체 계정 요금을 구분하세요. 배송 서비스와 추적 서비스는 서로 다른 과금 단위를 사용할 수 있으며, 통합 플랫폼은 기능을 다른 방식으로 묶어 제공할 수 있습니다. 실제로 운영하려는 정확한 워크플로에 대한 견적을 받거나 해당 요금제를 검토하세요.
과금 대상 사용량의 정의, 실패한 요청의 과금 여부, 반복적인 추적 제출의 처리 방식 및 사용량이 허용량을 초과할 때의 처리 방식을 문의하세요. 엔지니어링 유지 관리, 지원 업무 및 두 통합의 일관성을 유지하는 비용도 포함하세요. 정의된 배송 구성과 현재 상업 조건이 없다면 어느 범주가 더 저렴하다고 단정하는 것은 오해를 불러일으킬 수 있습니다.
보안 및 데이터 보존을 검토하세요
배송 통합은 수취인 주소와 통관 정보를 처리할 수 있습니다. 추적 통합 역시 배송 식별자와 관련 고객 데이터를 처리할 수 있습니다. 필요한 필드를 확인하고, 자격 증명에 필요한 액세스 권한만 부여하며, 브라우저 측 코드에 비밀 정보를 포함하지 마세요.
비즈니스 요구 사항에 따라 보존, 삭제 및 액세스 제어를 검토하세요. 편리한 통합이라고 해서 워크플로에 필요하지 않은 고객 정보를 전송해야 해서는 안 됩니다.
도입 전에 실행할 실용적인 검증 계획
빠른 시작 안내서의 성공 사례 하나만 사용하는 대신 대표적인 배송을 사용해 개념 증명을 실행하세요. 운영, 엔지니어링 및 고객 지원 팀과 허용 기준을 합의하세요.
- 발송: 필요한 라벨 형식을 생성하고 창고 장비에서 사용할 수 있는지 확인하세요.
- 주문 매핑: 원래 이력을 잃지 않고 분할 배송, 여러 소포 및 교체 배송을 테스트하세요.
- 추적: 비즈니스에 중요한 운송업체와 경로의 실제 이벤트 순서를 확인하세요.
- 예외: 조치가 필요한 배송 문제가 적절한 팀에 전달되는지, 모든 비정상 스캔이 자동으로 실패로 처리되지는 않는지 확인하세요.
- 복구: 요청 또는 웹훅 엔드포인트를 중단하고 애플리케이션이 누락된 정보를 어떻게 조정하는지 시연하세요.
- 커뮤니케이션: 지정된 시스템만 각 고객 알림을 보내는지 확인하세요.
- 상업적 적합성: 예상 사용량과 공급업체가 확인한 과금 정의를 사용해 요금을 추정하세요.
결정 원칙: 누락된 기능을 먼저 구매하세요. 발송이 이미 작동한다면 주문 처리를 다시 구축하지 않고 추적 통합을 평가하세요. 라벨 생성이 누락되었다면 먼저 배송 실행 문제를 해결하세요. 애플리케이션이 전체 배송 수명 주기를 담당한다면 두 기능을 모두 검증하고, 통합형 아키텍처와 분리형 아키텍처 중 어느 쪽이 팀에서 운영하기 쉬운지 선택하세요.
FAQ
배송 API에는 항상 추적 기능이 포함되나요?
아니요. 일부 서비스는 두 기능을 모두 포함하지만, 다른 서비스는 별도의 엔드포인트, 제품 또는 요금제를 통해 제공합니다. 추적 기능이 포함되어 있더라도 이를 구매 후 추적 솔루션으로 사용하기 전에 이벤트 세부 정보, 업데이트 전달 방식, 운송업체 지원 및 사용 조건을 확인하세요.
주문 처리 파트너가 생성한 라벨의 소포를 추적할 수 있나요?
가능할 수 있습니다. 애플리케이션에는 추적 통합에 필요한 식별자가 필요하며, 일반적으로 운송장 번호와 필요한 경우 운송업체 식별자 또는 추가 확인 정보가 포함됩니다. 파트너의 운송업체가 지원되는지 확인하고 운송장 번호가 시스템으로 안정적으로 전달되는지 확인하세요.
추적 API가 운송업체 스캔을 더 빨리 발생시키나요?
물리적인 운송업체 스캔을 생성할 수는 없습니다. 추적 소스를 통해 제공되는 정보를 애플리케이션이 조회, 정리 및 배포하도록 지원할 수 있습니다. API가 모든 이동에 대한 즉각적인 가시성을 보장한다고 가정하지 말고 실제 배송을 사용해 업데이트 동작을 평가하세요.
두 기능을 모두 사용하려면 API 공급업체가 두 곳 필요한가요?
아니요. 필요한 것은 두 개의 공급업체가 아니라 두 가지 기능입니다. 한 공급업체가 배송 및 추적 요구 사항을 충족한다면 해당 공급업체를 사용하세요. 별도로 분리하면 기존 워크플로를 유지하거나 통합 옵션이 충족하지 못하는 특정 요구 사항을 해결할 수 있을 때 기능을 분리하세요.
추적 API가 주문 관리 시스템을 대체할 수 있나요?
아니요. 추적 데이터는 주문 관리에 입력되는 정보이지 재고 할당, 주문 처리 결정, 결제 처리 또는 주문 레코드를 대체하지 않습니다. 애플리케이션은 여전히 각 배송을 올바른 주문에 연결하고 배송 이벤트가 비즈니스 워크플로에 어떤 영향을 미치는지 결정해야 합니다.
출처
- FedEx Ship API 문서 — 배송 생성, 라벨 및 배송 워크플로 요구 사항에 대한 참고 자료입니다.
- FedEx 추적 API 문서 — 추적 요청 및 배송 상태 정보에 대한 참고 자료입니다.
- 17TRACK Tracking API — 추적 통합 범주에 대한 공식 제품 참고 자료입니다.
- 17TRACK API 문서 — 추적 등록, 추적 데이터 및 푸시 알림 통합에 대한 참고 자료입니다.
