필요한 개발 문서는 이미 준비되어 있습니다
REST와 WebSocket, HMAC-SHA512 서명, Tier 기반 Rate Limit까지 프로덕션에 올리기 전 알아야 할 모든것을 한 페이지에 익숙한 관행 위에 규제 요건만 더했습니다.
Base URL
https://api.inexkr.com
버전
KRCX /0/ · Payment /v0.1/
금액 표기
모든 금액 · 수량은 문자열
시각
UTC · ISO 8601 (RFC 3339)
아래 내용은 실제 KRCX · Payment API 스펙을 반영한 예시입니다. 상세 명세는 연동 범위가 정해진 뒤 별도로 전달됩니다.
/0/private/AddOrder주문을 생성합니다. 트래블룰 메타데이터가 누락되면 게이트웨이 단계에서 거부됩니다.
Request
# KRCX Trading API는 form-urlencoded 방식입니다 POST /0/private/AddOrder Host: api.inexkr.com API-Key: <api_key> API-Sign: <base64(HMAC-SHA512)> Content-Type: application/x-www-form-urlencoded nonce=1719999999000 &pair=USDT%2FKRW &type=buy &ordertype=limit &volume=100.0 &price=1340.5 &timeinforce=GTC &userref=PARTNER-ORD-12345 # 컴플라이언스 필수 필드 &vasp_purpose_code=P2B_TRADE &originator_vasp_id=VASP-2024-XXXX &kyc_level=TIER2 &settlement_mode=INSTANT_KRW
Response
// 200 OK — 성공
{
"error": [],
"result": {
"descr": {
"order": "buy 100.00000000 USDT/KRW @ limit 1340.5"
},
"txid": ["INEX-TX-9F3D2A1B"],
"orderId": "9F3D2A1B",
"settlement": {
"mode": "INSTANT_KRW",
"expected_settle_time": "T+0",
"krw_account_linked": true
}
}
}
// 200 OK — 컴플라이언스 거부 (HTTP 상태는 200, error 배열 확인)
{
"error": ["ECompliance:Missing travel-rule metadata"],
"result": {}
}REST + WebSocket
단일 커넥션 위 멀티 구독
심볼 이중 표기
USDT/KRW · USDTKRW 모두 허용
Tier + Weight
먼저 도달하는 한도 적용
응답 키 중복 제공
txid · orderId 동시 반환
개발 관련 자주 묻는 질문
연동 전에 API 구조를 미리 확인할 수 있나요?
본 문서에서 엔드포인트 구조와 요청·응답 형식을 확인하실 수 있습니다. 연동 범위가 정해지면 상세 명세와 연동 가이드를 별도로 전달해 드립니다.
기존 거래소 API 연동 경험을 재사용할 수 있나요?
Kraken 스타일 구조를 기본 골격으로 채택하고 HashKey·Binance 스타일 별칭 엔드포인트를 병행 제공합니다. 심볼 표기와 응답 키도 두 방식을 모두 지원합니다.
Rate Limit은 어떻게 계산되나요?
Tier별 분당 호출 한도와 엔드포인트별 Weight 한도를 함께 적용하며, 둘 중 먼저 도달하는 쪽이 우선합니다.
Webhook 서명은 어떻게 검증하나요?
전달되는 서명 헤더로 페이로드 무결성을 검증할 수 있습니다. 구체적인 검증 절차는 연동 가이드에서 안내합니다.
nonce는 어떻게 관리해야 하나요?
nonce는 API Key별로 항상 증가하는 값이어야 합니다. 밀리초 단위 Unix 타임스탬프 사용을 권장합니다. 여러 서버에서 같은 Key로 동시에 호출하면 nonce 역전이 발생할 수 있으므로, 서버별로 Key를 분리하거나 중앙에서 채번하는 구조를 권장합니다.
같은 주문이 중복 생성되는 것을 어떻게 막나요?
요청에 파트너 자체 주문 추적 ID(userref)를 포함하면 이후 조회로 중복 여부를 확인할 수 있습니다. 네트워크 타임아웃으로 응답을 받지 못한 경우에는 곧바로 재시도하지 말고 주문 조회 엔드포인트로 상태를 먼저 확인하십시오.
WebSocket 연결이 끊기면 어떻게 처리하나요?
재연결 후 구독을 다시 설정해야 하며 Private 채널은 토큰을 새로 발급받아야 합니다. 연결이 끊긴 구간의 체결과 잔고 변동은 REST 조회 엔드포인트로 보정하는 것을 권장합니다. 하트비트가 일정 시간 오지 않으면 연결을 끊고 재접속하도록 구현하십시오.
에러가 났을 때 재시도해도 되나요?
에러 계열에 따라 다릅니다. Rate limit 초과는 잔여 쿨다운 이후 재시도가 가능합니다. ECompliance와 EOrder 계열은 요청 내용 자체를 수정해야 하므로 그대로 재시도하면 동일하게 거부됩니다. 5xx 응답은 지수 백오프로 재시도하되, 주문 계열은 상태를 먼저 조회한 뒤 재시도하십시오.
Webhook을 받지 못하면 재전송되나요?
2xx 응답을 받지 못하면 일정 간격으로 재전송합니다. 동일 이벤트가 두 번 이상 도착할 수 있으므로 이벤트 ID를 기준으로 멱등 처리해야 합니다. 수신 엔드포인트는 빠르게 2xx를 반환하고 실제 처리는 비동기로 분리하는 구조를 권장합니다.
수량과 금액의 소수점 자릿수는 어떻게 되나요?
자산과 거래쌍마다 다릅니다. AssetPairs 엔드포인트에서 최소 주문 수량, 호가 단위, 허용 소수점 자릿수를 확인할 수 있습니다. 금액은 부동소수점 대신 문자열 또는 정수 최소단위로 처리해 반올림 오차를 피하십시오.
시간대와 타임스탬프 기준은 무엇인가요?
응답에 포함되는 시각은 UTC 기준 ISO 8601 형식이며, nonce와 timestamp는 밀리초 단위 Unix 시간입니다. 서버 시간과의 오차는 Time 엔드포인트로 확인할 수 있으며, 서명 검증 실패의 상당수는 서버 시각 오차에서 발생합니다.
조회 결과가 많을 때 페이지네이션은 어떻게 하나요?
체결 내역과 주문 내역 조회는 기간 파라미터와 커서 기반 페이지네이션을 지원합니다. 대량 조회 엔드포인트는 Weight가 높게 책정되어 있으므로 배치 간격을 두고 호출하시기 바랍니다.
IP 화이트리스트는 필수인가요?
Enterprise Tier 이상은 필수이며 그 이하 등급에도 적용을 권장합니다. 호출 서버가 늘어나는 경우 사전에 등록해야 하고, 미등록 IP에서 온 요청은 인증 단계에서 거부됩니다.
SDK를 제공하나요?
REST와 WebSocket 모두 표준 규격을 따르므로 별도 SDK 없이 연동할 수 있습니다. 주요 언어의 예제 코드와 연동 가이드를 함께 제공하며, 필요 시 연동 과정에서 기술 지원을 제공합니다.
연동 검증은 어떤 순서로 진행하나요?
요청·응답 형식 확인, KYC/AML 정책 검증, 정산 시나리오 점검, 보안 점검 순으로 진행합니다. 각 단계에서 확인할 항목과 통과 기준은 연동 가이드에서 안내합니다.
API 버전이 올라가면 기존 연동이 깨지나요?
하위 호환을 원칙으로 합니다. 파괴적 변경이 필요한 경우 사전 공지와 이행 기간을 두고 진행합니다. Payment와 Remittance API는 v0.1 초안 단계로 Trading API 대비 변경 가능성이 상대적으로 높습니다.
Get Started
INEX와 함께 시작하십시오
도입 검토 단계에 맞춰 필요한 자료와 논의를 제공합니다. 기술 검토와 규제 요건 정리를 함께 진행합니다.