사은품 지급 대상인데 송장은 없다: 재고대기와 지급취소를 나누는 배송 연동
에이픽 서비스를 소개하는 홍보 글입니다. 현실적인 업무를 바탕으로 구성한 가상 시나리오이며 실제 고객 후기나 실측 성과가 아닙니다. 공식 문서의 2026-11-05 확인 기록을 기준으로 작성했습니다. 아래 요청·응답은 미실행 정적 예시입니다.
반복 작업은 어디에서 시작되는가
프로모션 기간에 본품은 물류센터에서, 사은품은 협력 창고에서 발송하는 판매사를 가정합니다. 고객의 주문 화면에는 본품 송장 하나만 있어 사은품 누락 문의가 반복됩니다. 담당자는 프로모션 명단을 열어 별도 송장을 찾아 전달합니다.
자동화할 단위를 먼저 정합니다
상품 배송과 사은품 배송을 서로 다른 배송 유형으로 연결합니다. 사은품 지급 조건 충족 여부는 주문 시스템에서 판단하고 택배 조회 API에 그 판단을 맡기지 않습니다. 확정된 사은품 송장만 APICK 조회 대상으로 보냅니다.
apick.app에서 서버 연결을 준비합니다
공식 홈페이지에서 해당 상품의 최신 개발가이드와 이용 조건을 확인하고 계정을 준비합니다. 인증키는 서버 환경변수 APICK_API_KEY로 읽고 브라우저·앱·공개 저장소에 넣지 않습니다. 키를 출력하는 디버그 로그도 끕니다. 아래 네 장은 공통 준비 절차를 보여주는 2026-10-28 공개 보관 화면이며, 이 상품을 실행한 결과 사진이 아닙니다. 당시 화면의 상품 수나 표시는 현재 상태를 보증하지 않습니다.
공식 요청과 마스킹 응답 예시
승인된 업무의 송장과 현재 공식 허용 택배사 코드를 서버 환경변수에 연결하는 구조입니다. 실제 값과 실제 API 키는 포함하지 않았습니다. 두 예시는 서로 다른 선택 경로이며 같은 건에 모두 연속 실행하라는 뜻이 아닙니다.
# 공식 명세 기반 정적 예시이며 실제 요청을 실행하지 않았습니다.
curl --fail-with-body --request POST 'https://apick.app/rest/parcel_tracking' \
--header "Authorization: Bearer $APICK_API_KEY" \
--form-string "carrier=${APICK_CARRIER}" \
--form-string "trackingNumber=${APICK_TRACKING_NUMBER}"
# 택배사를 모르는 건만 별도로 검토하는 자동인식 경로
curl --fail-with-body --request POST 'https://apick.app/rest/parcel_tracking_auto' \
--header "Authorization: Bearer $APICK_API_KEY" \
--form-string "trackingNumber=${APICK_TRACKING_NUMBER}"아래는 공식 응답 일부 구조의 정적 예시입니다. 송장번호를 마스킹했으며 실제 배송이 완료됐다는 증거가 아닙니다.
{
"data": {
"carrier": {
"code": "cj",
"name": "CJ대한통운"
},
"trackingNumber": "[마스킹]",
"status": "DELIVERED",
"carrierStatus": "배달완료"
}
}
우리 업무 화면에는 이렇게 연결합니다
조회된 상태 옆에 본품인지 사은품인지 표시하면 같은 고객의 서로 다른 배송을 혼동하지 않을 수 있습니다. 고객에게 노출할 때에는 본인 주문에 연결된 배송건만 서버에서 선택하고 송장번호 입력만으로 타인의 배송 화면을 열지 않습니다.
사은품 지급 약속을 세 단계로 나눕니다
예를 들어 프로모션 조건을 충족한 주문 A와, 결제 취소로 조건을 잃은 주문 B, 조건은 충족했지만 사은품 재고가 없는 주문 C를 가정합니다. A는 지급 대상 확정 뒤 출고 준비로, B는 약관과 고객 안내 기준을 확인한 뒤 지급 취소 검토로, C는 재고 대기로 분류합니다. 이 세 주문에 아직 송장이 없다면 택배 API를 호출하지 않습니다. 송장 없음이라는 같은 결과 뒤에 서로 다른 다음 작업이 있기 때문입니다.
지급 대상 확정은 판매자의 프로모션 조건과 주문 기록으로 판단하는 내부 규칙입니다. APICK이 구매 금액이나 쿠폰 조건, 사은품 재고를 판정하는 기능이 아닙니다. 대상 확정시각과 적용한 행사 조건 버전을 내부 기록에 남기고, 담당자가 수동으로 대상을 바꾸면 사유를 남기는 방식으로 설계할 수 있습니다.
재고 대기는 물류 출고팀이 출고 가능 여부를 갱신하고, 지급 취소 검토는 고객 안내와 행사 약관을 확인할 담당자에게 연결합니다. 본품 배송완료 상태는 두 판단의 근거가 아닙니다. 사은품을 이미 발송한 뒤 본품이 취소됐다면 기존 송장을 삭제하거나 자동 회수됐다고 표시하지 않고, 사후 처리 검토를 별도 업무로 남깁니다.
지급 대상 확정→재고 준비→사은품 송장 등록 이후에만 APICK 배송 상태를 연결합니다. 여기서 화살표로 나타낸 단계명은 설명을 위한 우리 시스템의 예시 상태이며 APICK 응답 필드가 아닙니다. 사은품이 누락됐다는 문의가 오면 송장 조회부터 반복하기보다 어느 내부 단계에서 멈췄는지 먼저 확인하는 것이 이 시나리오의 중심입니다.
예외를 숨기지 않고 분리합니다
사은품 미대상, 발송 준비, 배송 조회 가능은 다른 상태입니다. 아직 발송되지 않은 사은품을 API 장애로 표시하거나 배송완료인 본품을 사은품 완료 근거로 쓰지 않습니다. 문의 담당자는 조건 확인과 배송 확인을 나누어 대응합니다.
비용과 확인 조건
공식 문서는 국내외38개 택배사와 자동 택배사 인식을 안내합니다. 지정조회 기본요금은5P, 실패·정보없음은 무과금 안내이며 자동인식 단가를 같은5P로 가정하지 않습니다. 택배사를 알 때 지정조회가 빠르고 저렴하다는 안내를 참고하세요. 공개 상태표의 확인 중 표시만으로 전체 정상이나 전체 장애를 단정하지 않습니다.
도입 효과는 무엇으로 확인할까
프로모션이 끝나면 미발송 목록과 조회 실패 목록을 따로 검토합니다. 사은품 배송비나 지급 비용은 이 API 요금과 별도이며, 배송 상태만으로 프로모션 이익을 계산할 수는 없습니다. 반복 조회 업무가 줄었는지는 담당자 처리 기록으로 평가합니다.
이 글은 직접 구현할 업무 흐름 제안이며 에이픽이 완성된 관리 화면이나 자동 알림 시스템까지 제공한다는 뜻이 아닙니다. 실제 처리시간을 측정하지 않았으므로 밤새던 작업이 몇 분에 끝났다는 실적을 주장하지 않습니다. 승인 대기·기관 응답·예외 검토 시간을 포함해 작은 적법한 범위에서 확인한 뒤 확대 여부를 결정하세요.
실제 이름·전화번호·차량번호·송장·통관부호·거래 식별자·문서 원문은 공개 글과 공유 로그에서 제외합니다. 내부 저장도 목적과 권한·보관기간을 정하고 원문 전체를 불필요하게 복제하지 않습니다.
공식 서비스: apick.app · 개발가이드: parcel_tracking
댓글 없음:
댓글 쓰기