카페24 주문 API로 주문 데이터를 가져와 ERP·정산에 활용하는 방법

카페24 관리자에서 주문을 확인하는 것만으로 충분한 쇼핑몰도 많습니다.

하지만 주문량이 많아지거나 외부 프로그램과 연결해야 하는 경우에는 관리자 화면에서 직접 주문을 내려받는 방식만으로는 한계가 생길 수 있습니다.

예를 들어 다음과 같은 기능이 필요할 수 있습니다.

이런 기능을 개발할 때 사용할 수 있는 방법 중 하나가 카페24 API입니다.

카페24 API를 이용하면 주문 목록과 주문 상세, 상품·옵션, 배송 정보 등의 데이터를 외부 시스템에서 활용할 수 있습니다.

다만 단순히 “주문 API를 호출하면 된다”는 구조는 아닙니다.

카페24 인증 → 주문 조회 → 데이터 저장·가공 → 외부 시스템 전달이라는 전체 흐름을 설계해야 안정적으로 운영할 수 있습니다.

카페24 주문 API는 쇼핑몰의 주문 데이터를 다른 프로그램에서 사용할 수 있도록 연결해 주는 기능입니다.

예를 들어 카페24에서 주문이 발생하면 API를 통해 주문 정보를 가져와 다음과 같은 시스템에서 활용할 수 있습니다.

카페24 쇼핑몰 → 주문 API → 외부 서버 → ERP·물류·정산·관리 화면

관리자가 카페24에서 엑셀을 내려받아 다시 다른 프로그램에 입력하는 대신, 필요한 데이터를 자동으로 가져와 처리할 수 있다는 것이 가장 큰 차이입니다.

다만 API에서 가져올 수 있는 데이터와 사용할 수 있는 기능은 필요한 권한과 API 범위에 따라 달라질 수 있으므로, 개발 전에 필요한 데이터를 먼저 정하는 것이 중요합니다.

주문 API를 이용할 때는 먼저 어떤 주문 정보가 필요한지를 정해야 합니다.

예를 들어 주문 목록에서는 주문번호, 주문일, 주문 상태 등의 기본 정보를 확인하고, 실제 정산이나 물류 처리를 위해서는 주문 상세와 상품·옵션 정보가 추가로 필요할 수 있습니다.

주로 다음과 같은 데이터를 활용합니다.

특히 ERP나 정산 시스템으로 주문을 보내려면 주문 목록만 가져오는 것으로 부족한 경우가 많습니다.

예를 들어 하나의 주문에 여러 상품과 옵션이 들어 있다면 상품별 수량과 금액까지 확인해야 정확한 정산이나 재고 처리가 가능합니다.

카페24 주문 API 연동은 일반적으로 다음과 같은 순서로 진행합니다.

1. 카페24 API 인증

먼저 외부 프로그램이 카페24 쇼핑몰의 데이터를 사용할 수 있도록 인증을 진행합니다.

카페24 API는 OAuth 방식의 인증을 사용하며, 필요한 API 권한을 설정해야 합니다.

예를 들어 주문을 조회하는 기능과 주문 상태를 변경하는 기능은 필요한 권한이 다를 수 있습니다.

2. 주문 데이터 조회

인증이 완료되면 필요한 조건으로 주문 데이터를 조회합니다.

예를 들어 특정 기간이나 특정 주문 상태를 기준으로 주문을 가져올 수 있습니다.

3. 주문 상세 확인

ERP, 정산, 물류 등에서 상품 단위의 정보가 필요하다면 주문 상세와 상품·옵션 데이터를 추가로 확인합니다.

4. 외부 시스템으로 전달

가져온 주문 데이터를 ERP, WMS, 정산 시스템 또는 자체 관리 화면으로 전달합니다.

5. 처리 결과 저장

어떤 주문을 처리했는지 서버에 기록해 두면 중복 전송이나 누락을 방지하기 쉽습니다.

전체 구조는 다음과 같이 볼 수 있습니다.

카페24 → API → 별도 서버 → 데이터 저장·가공 → ERP·정산·관리 화면

주문 데이터를 가져오는 방법은 크게 정기적으로 조회하는 방식과 주문 발생을 알려받는 방식으로 나눌 수 있습니다.

정기 조회 방식

일정한 시간마다 카페24 API를 호출해 새로운 주문을 확인하는 방식입니다.

예를 들어 10분마다 새로운 주문을 확인하거나 하루에 한 번 주문 데이터를 모아서 처리할 수 있습니다.

실시간 처리가 필요하지 않은 정산이나 통계 업무라면 이러한 방식으로도 충분할 수 있습니다.

웹훅 방식

주문이나 상태 변경과 같은 이벤트가 발생했을 때 카페24에서 외부 서버로 알려주는 방식입니다.

주문이 발생하거나 상태가 변경되는 것을 빠르게 외부 시스템에 반영해야 한다면 웹훅을 함께 검토할 수 있습니다.

다만 웹훅만으로 모든 상황을 완벽하게 처리하기보다는 웹훅 + API 재조회 구조를 사용하는 경우도 있습니다.

예를 들어 웹훅이 정상적으로 도착하면 주문을 처리하고, 누락 가능성이 있는 데이터는 일정 시간마다 API로 다시 확인하는 방식입니다.

API를 사용한다고 해서 카페24와 ERP를 브라우저에서 직접 연결하는 방식으로 개발하는 것은 적절하지 않은 경우가 많습니다.

API 인증에 필요한 토큰이나 클라이언트 정보를 안전하게 관리하고, 주문 데이터를 저장하며, 실패한 작업을 다시 처리하려면 별도의 서버가 필요할 수 있습니다.

일반적인 구조는 다음과 같습니다.

카페24 → API·웹훅 → 별도 서버 → DB → ERP·정산·물류 시스템

별도 서버에서는 다음과 같은 작업을 담당할 수 있습니다.

특히 주문량이 많은 쇼핑몰이라면 API를 호출하는 것보다 데이터를 안정적으로 관리하는 구조를 만드는 것이 중요합니다.

주문 데이터를 외부에서 활용하면 다양한 자동화 기능을 만들 수 있습니다.

ERP 주문 자동 전송

카페24에서 발생한 주문을 ERP로 자동으로 보내 상품, 수량, 주문자 등의 정보를 관리할 수 있습니다.

물류 시스템 연동

주문 데이터를 WMS나 3PL 물류 시스템으로 전달해 출고 작업을 자동화할 수 있습니다.

매출·수당 계산

가맹점, 대리점, 디자이너, 파트너별로 판매된 주문을 구분해 매출이나 수당을 계산할 수 있습니다.

별도 주문 관리 화면

카페24 관리자에서 제공하는 화면과 별도로 회사 내부 업무에 필요한 주문만 모아 관리할 수 있습니다.

주문 상태 연동

주문·배송·취소 등의 상태를 외부 시스템과 연결해 서로 같은 정보를 사용하도록 만들 수 있습니다.

이때 중요한 것은 주문을 읽기만 하는지, 아니면 카페24의 주문 상태까지 변경해야 하는지를 구분하는 것입니다.

읽기만 하는 연동과 카페24 데이터를 변경하는 연동은 필요한 권한과 개발 범위가 달라질 수 있습니다.

모든 주문 자동화에 API 개발이 필요한 것은 아닙니다.

단순히 주문 데이터를 엑셀로 내려받아 사용하는 정도라면 카페24 관리자 기능으로 충분할 수 있습니다.

또한 필요한 기능을 제공하는 앱이 있다면 앱을 이용하는 방법도 있습니다.

예를 들어 다음과 같은 경우에는 먼저 기본 기능이나 앱을 확인하는 것이 좋습니다.

반대로 다음과 같은 요구가 있다면 API와 별도 서버를 검토할 가능성이 높습니다.

주문 연동을 처음 개발할 때 자주 발생하는 실수가 주문 목록 데이터만 가져오는 것입니다.

주문 목록에는 기본적인 주문 정보가 있지만 실제 업무에 필요한 상품·옵션 정보나 상세 금액이 부족할 수 있습니다.

예를 들어 한 주문에 다음과 같이 여러 상품이 포함되어 있다고 가정해 보겠습니다.

주문번호 10001

ERP나 정산 시스템에서는 상품별 수량과 옵션, 금액이 필요할 수 있습니다.

따라서 개발 전에 다음을 먼저 확인해야 합니다.

주문 단위 정보가 필요한가?

상품 단위 정보가 필요한가?

옵션 정보가 필요한가?

배송 정보가 필요한가?

취소·환불 정보가 필요한가?

필요한 데이터에 따라 API 조회 범위를 정해야 합니다.

외부 시스템 연동에서 중요한 문제 중 하나가 중복 처리입니다.

예를 들어 같은 주문을 ERP에 두 번 전송하면 실제 주문이 중복 등록될 수 있습니다.

웹훅이 같은 이벤트를 여러 번 전달하거나, 서버에서 처리한 주문을 다시 조회하는 경우에도 이런 문제가 발생할 수 있습니다.

따라서 서버에 처리 기록을 남기고 이미 처리한 주문인지 확인하는 과정이 필요합니다.

예를 들어 주문번호와 상품 정보, 처리 상태 등을 기준으로 중복 여부를 확인할 수 있습니다.

또한 외부 시스템 전송에 실패했다면 처음부터 모든 주문을 다시 처리하는 것이 아니라 실패한 주문만 다시 처리할 수 있는 구조를 만드는 것이 좋습니다.

주문량이 많은 쇼핑몰에서는 API 호출 제한도 고려해야 합니다.

모든 주문을 한꺼번에 반복해서 조회하면 API 호출이 많아지고 처리 속도가 느려질 수 있습니다.

따라서 다음과 같은 방법을 사용할 수 있습니다.

예를 들어 매번 쇼핑몰의 전체 주문을 처음부터 다시 가져오는 방식보다는 마지막으로 처리한 시점 이후의 주문만 확인하는 방식이 효율적입니다.

카페24 API 연동에서는 인증 정보의 보안도 중요합니다.

API 인증에 사용하는 토큰이나 클라이언트 시크릿 같은 정보는 쇼핑몰의 스킨이나 브라우저에 직접 넣어서는 안 됩니다.

일반적으로 이러한 정보는 외부 서버에서 안전하게 관리합니다.

브라우저·쇼핑몰 스킨 → API 인증 정보 노출 위험

보다는

쇼핑몰 → 별도 서버 → 카페24 API

와 같은 구조로 구성하는 것이 적절합니다.

또한 테스트 쇼핑몰과 실제 운영 쇼핑몰의 인증 정보도 구분해 관리하는 것이 좋습니다.

주문 연동에서 특히 주의해야 하는 부분이 부분 취소와 환불입니다.

예를 들어 한 주문에서 상품 3개 중 1개만 취소되는 경우 전체 주문이 취소되는 것과 처리 방법이 다릅니다.

따라서 취소나 환불을 처리하기 전에 현재 주문 상태와 상품별 수량, 금액 등을 다시 확인하는 과정이 필요할 수 있습니다.

특히 외부 ERP나 정산 시스템과 연결되어 있다면 다음과 같은 상황을 함께 처리해야 합니다.

이런 조건이 많을수록 단순한 주문 조회 API보다 별도의 주문 상태 관리 로직이 필요해집니다.

개발 전에 다음 내용을 정리하면 불필요한 개발 범위를 줄일 수 있습니다.

1. 어디로 보내나요?

ERP, 물류 시스템, CRM, 정산 시스템 등 외부 시스템을 정합니다.

2. 어떤 데이터를 보내나요?

주문번호, 상품, 옵션, 수량, 금액, 배송 정보 등 필요한 항목을 정합니다.

3. 얼마나 자주 보내나요?

실시간에 가까운 연동인지, 10분·1시간·하루 단위의 배치인지 정합니다.

4. 주문 상태도 변경하나요?

카페24에서 주문을 읽기만 하는지, 외부 시스템의 처리 결과를 다시 카페24에 반영해야 하는지 확인합니다.

5. 취소·환불도 연동하나요?

부분 취소와 환불까지 포함할지 결정합니다.

6. 실패하면 어떻게 하나요?

연동 실패 시 자동 재시도할지, 관리자가 직접 재처리할지 정합니다.

7. 데이터를 얼마나 보관하나요?

주문 데이터와 개인정보를 어떤 범위까지 저장할지 정합니다.

이 내용을 먼저 정하면 API 개발 범위와 서버 구성을 보다 정확하게 결정할 수 있습니다.

주문 목록만 가져와 상품·옵션 정보가 부족함

→ ERP나 정산에 필요한 주문 상세와 품목 데이터를 함께 확인해야 합니다.

같은 주문이 외부 시스템에 두 번 등록됨

→ 처리 기록과 중복 방지 로직이 필요합니다.

API 인증 정보를 스킨에 넣음

→ 인증 정보가 노출될 수 있으므로 서버에서 관리해야 합니다.

부분 취소를 전체 취소처럼 처리함

→ 주문 상세와 상품별 수량·금액을 다시 확인하는 과정이 필요합니다.

웹훅이 실패했는데 주문이 누락됨

→ 웹훅과 함께 보완 조회나 재처리 기능을 고려할 수 있습니다.

주문이 많아지면서 API 호출이 느려짐

→ 조회 범위와 처리 주기를 나누고 이미 처리한 주문을 반복해서 가져오지 않도록 설계해야 합니다.

옴니어스24는 단순히 “카페24 주문 API를 연결해 주세요”라는 요청만으로 개발 범위를 정하지 않습니다.

먼저 주문 데이터를 어디에 사용하려는지부터 확인합니다.

예를 들어 다음과 같은 내용을 확인합니다.

그다음 필요한 API 권한과 데이터 범위를 정하고, 필요하다면 별도 서버와 DB를 구성합니다.

또한 API 연동에서는 로그, 중복 방지, 실패 재처리가 중요하기 때문에 정상적으로 주문이 전달되는 것뿐 아니라 문제가 발생했을 때 다시 처리할 수 있는 구조까지 함께 검토합니다.

단순한 엑셀 작업이나 앱으로 해결할 수 있는 부분이라면 API 개발을 무리하게 권하지 않고, 실제로 자동화가 필요한 부분을 중심으로 범위를 정하는 방식이 효율적입니다.