Grind away: 통관부호 확인 때문에 출고가 밀린다면: 에이픽 API로 고객 승인부터 주문 상태까지 연결하기

2026년 11월 5일 목요일

통관부호 확인 때문에 출고가 밀린다면: 에이픽 API로 고객 승인부터 주문 상태까지 연결하기

에이픽 API 활용 시나리오 · 가상 업무 사례이며 실제 고객 후기나 처리시간 실측이 아닙니다. 요청·응답은 공식 개발가이드 기반 정적 예시입니다. 개인정보는 비공개 표식으로 바꿨고 실제 API 호출은 하지 않았습니다.

출고 마감 30분 전, “통관부호 다시 보내주세요”가 반복된다면

해외 구매대행 운영팀의 가상 상황입니다. 주문은 정상 접수됐지만 고객이 개인통관고유부호를 잘못 입력하거나 찾지 못해 확인 문의가 계속 쌓입니다. 담당자는 대화창을 열고 값을 복사한 뒤 주문표에 다시 적습니다. 한 자리라도 잘못 옮기면 고객에게 다시 연락해야 합니다.

이 업무에서 바꾸고 싶은 것은 고객의 본인 확인을 건너뛰는 일이 아닙니다. 고객이 승인한 조회 결과를 주문 시스템에 연결해, 담당자가 같은 정보를 다시 입력하지 않게 하는 것입니다. APICK의 개인통관고유부호 조회는 기존 부호를 확인하는 API이며 새 부호 발급 API가 아닙니다.

먼저 준비할 것은 화면 자동화가 아니라 서버 연동입니다

apick.app에서 계정을 준비하고 개발가이드의 API 키 안내를 확인합니다. 서비스 서버는 환경변수 APICK_API_KEY로 인증키를 읽습니다. 브라우저나 모바일 앱에 키를 넣지 않고, 공개 저장소와 화면 캡처·로그에도 키 값이 나오지 않게 합니다. 아래 네 장은 공개된 공통 시작 화면을 다시 확인한 자료이며, 이 글의 상품 API를 실제 실행한 사진은 아닙니다.

상품과 개발가이드로 이동하는 에이픽 공개 홈. 당시 메뉴 화면이며 현재 상품 수를 뜻하지 않습니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

계정 준비 단계에서 만나는 빈 회원가입 양식. 정보 입력이나 가입 실행 화면이 아닙니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

서버 환경변수에 인증키를 보관하는 공통 시작 가이드. 실제 키 값은 없는 공개 문서입니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

1. 고객에게 인증을 요청하고 요청 식별자를 보관합니다

이름·생년월일·본인 명의 휴대전화번호와 간편인증 수단을 받습니다. 이 API의 필드 이름은 birthday와 provider입니다. 다른 간편인증 API의 birthDate·authProvider를 그대로 복사하면 안 됩니다.

# 공식 명세 기반 정적 예시. 실제 호출을 수행하지 않았습니다.
curl --fail-with-body --request POST 'https://apick.app/rest/req_pccc' \
  --header "Authorization: Bearer $APICK_API_KEY" \
  --form-string 'name=[이름 비공개]' \
  --form-string 'birthday=[생년월일 비공개]' \
  --form-string 'phone=[전화번호 비공개]' \
  --form-string 'provider=kakao'

공식 응답 예시에서 필요한 필드만 발췌하고 식별자를 제거했습니다. pending은 발송 후 승인 대기 상태이지 통관부호 확보 완료가 아닙니다.

{
  "data": {
    "tx_id": "[요청 식별자 비공개]",
    "status": "pending",
    "message": "인증 대기중입니다.",
    "success": 1
  },
  "api": {
    "success": true,
    "cost": 20
  }
}

공통 연결 확인용 /rest/info의 정적 cURL 화면. 아래 상품 API의 호출 결과가 아닙니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

2. 본인 승인 후 같은 tx_id로 결과를 확인합니다

# 공식 명세 기반 정적 예시. 실제 호출을 수행하지 않았습니다.
curl --fail-with-body --request POST 'https://apick.app/rest/get_pccc' \
  --header "Authorization: Bearer $APICK_API_KEY" \
  --form-string 'tx_id=[앞 단계 요청 식별자 비공개]'

다음은 공식 verified 예시의 일부입니다. 실제 개인정보나 실측 응답이 아니며, 개인통관고유부호·이름·주소·전화번호는 모두 제거했습니다.

{
  "data": {
    "status": "verified",
    "개인통관고유부호": "[비공개]",
    "이름": "[비공개]",
    "주소": "[비공개]",
    "전화번호": "[비공개]",
    "사용여부": "사용",
    "success": 1
  },
  "api": {
    "success": true,
    "cost": 20
  }
}

3. 확인된 주문과 고객 확인이 필요한 주문을 분리합니다

주문 관리 화면에는 승인 대기, 조회 중, 부호 확인 완료, 고객 안내 필요를 나누어 표시하도록 설계합니다. verified여도 부호가 없는 응답이 있으므로 상태 한 줄만 보고 출고 준비 완료로 바꾸지 않습니다. 실제 부호 수신 여부와 업무 조건을 함께 확인해야 합니다. 통관 가능 여부 전체를 이 API 하나가 보장하는 것도 아닙니다.

동일 계정의 대기 요청이나 30초 이내 요청이 재사용될 수 있으며 대상자가 달라도 영향을 받습니다. 앞 요청이 끝나기 전에 여러 고객의 인증을 동시에 발송하지 않습니다. 5분 승인 기한과 expires_at을 확인하고 고객이 거절하거나 취소하면 멈춥니다.

요금은 요청과 결과를 따로 봅니다

공식 안내상 인증 요청이 실제 발송되면20P, 조회 완료 후 부호가 있으면 결과20P입니다. 따라서 두 단계가 모두 과금되는 기본 흐름은40P입니다. verified이지만 부호가 없으면 결과 조회는 무과금이고, 이미 발생한 인증 요청 비용과는 별개입니다. 무료 포인트로 이용할 수 없으며 최소1회 결제 조건을 확인해야 합니다. 결과는 확인 시각부터24시간 안에 같은 tx_id로 재조회할 수 있지만 개인통관부호 결과 재조회는 매번 과금된다는 안내가 있습니다. 완료 결과를 받은 뒤 무의미하게 계속 조회하지 마세요. 실제 차감은 각 응답의 api.cost로 확인합니다.

담당자가 부호를 받아 옮겨 적는 대신, 고객 승인과 확인 결과를 주문 흐름 안으로 연결해 보세요.

도입 전에 확인할 세 가지

첫째, 고객의 요청과 적법한 처리 근거를 확인하고 필요한 정보만 받습니다. 둘째, 서버 로그에는 키·개인정보·원문 응답을 남기지 않고 접근권한과 보관기간을 정합니다. 셋째, HTTP 200만으로 성공 처리하지 말고 업무 상태와 오류, api.cost를 함께 확인합니다.

“밤새 반복하던 작업을 몇 분 만에 끝냈다”는 표현은 실제 처리시간을 측정한 뒤에만 사용할 수 있습니다. 이 시나리오에서는 반복 입력과 옮겨 적기를 줄이는 흐름을 제안합니다. 승인 대기·기관 응답·예외 검토까지 포함한 총시간은 보장하지 않습니다.

공식 명세: 인증 요청 · 결과 조회. 적용 전 최신 조건을 확인하세요.

Grind away