공통 응답 형식: 성공·실패 모두 동일 형식 — { "result": <ResultCode>, "data"?: object|string, "message"?: string }. result는 결과 코드 enum으로, SUCCESS·FAIL(일반 실패) 외 도메인별 구체 코드(SHOP_NOT_FOUND·NO_ROBOT_AVAILABLE·ORDER_DUPLICATE·VALIDATION_FAILED 등)가 사용됨. data·message는 있을 때만 노드 발현. message는 주로 실패 사유 설명에 사용
시간: ISO 8601, 타임존 +09:00 (KST) — 비스캣이 응답·콜백으로 내보내는 모든 시각이 동일 표기 (예: 2026-06-04T14:30:00+09:00) · 식별자: UUID v7
인바운드 인증:두 헤더 모두 필수 — X-Api-Key-Id(발급받은 업체 식별자, 예: automata) + X-Api-Key(비스캣이 발급한 고정 키). 서버는 업체별 키 대조로 인증합니다(불일치·미지 식별자 시 401 UNAUTHORIZED). 아래 「API 키 취급 주의」 참조
유니크 키 (재시도 안전): 배차 요청은 Idempotency-Key 헤더 필수, 그 외 POST는 권장 (24h 캐시 — 같은 키 재호출 시 첫 응답 그대로 반환)
발급 주체·범위:X-Api-Key는 비스캣이 오토메타 전용으로 발급합니다 (오토메타 ↔ 비스캣 통신 한정, 다른 연동 파트너와 공유·재사용 불가). 환경별(dev / staging / prod)로 별도 키가 발급되며, 유출 시 즉시 폐기·재발급 절차가 가동됩니다.
서버 간 통신 한정: 이 키는 오토메타 백엔드에서만 보관·사용하세요. 클라이언트(사용자 앱·웹 브라우저·점주 KDS 화면 등)에 절대 노출하지 마세요 — 모바일 앱 번들, 프런트엔드 JS, 인앱 WebView, 점주용 PC 화면, Git 커밋, 로그 평문 출력 등 어떤 형태로도 외부로 나가지 않아야 합니다.
대안 흐름: 사용자/점주 화면에서 비스캣 API의 데이터가 필요한 경우, 오토메타 백엔드를 경유해 가져온 결과를 클라이언트에 전달하세요. 클라이언트가 비스캣을 직접 호출하지 않습니다.
로그·디버깅: 디버그 로그·에러 리포트·HAR/네트워크 캡처를 외부와 공유할 때 X-Api-Key 값은 반드시 마스킹하세요.
2. 10종 API 목록
#
API
방향
Method / Path
인증
0
접속·인증 확인 (연동 초기 점검)
오토메타 → 비스캣
GET /v1/automata/ping
API Key
1
배송 가능 여부 (주문 이후)
오토메타 → 비스캣
POST /v1/automata/delivery/availability
API Key
2
로봇 배차 요청
오토메타 → 비스캣
POST /v1/automata/dispatch
API Key + Idempotency
3
로봇 배차 취소
오토메타 → 비스캣
POST /v1/automata/dispatch/{orderId}/cancel
API Key
4-A
위치기반 실시간 배송정보 (단발 조회)
오토메타 → 비스캣
GET /v1/automata/dispatch/{orderId}/tracking
API Key
4-B
위치기반 실시간 배송정보 (SSE 스트리밍)
오토메타 → 비스캣
GET /v1/automata/dispatch/{orderId}/tracking/stream
API Key
5
고객 도착 예상시간 조회
오토메타 → 비스캣
GET /v1/automata/dispatch/{orderId}/eta
API Key
6
매장(점포) 도착
비스캣 → 오토메타
POST {콜백URL} (robot.shop_arrived)
HMAC 서명
7
배달 출발 알림
비스캣 → 오토메타
POST {콜백URL} (delivery.departed)
HMAC 서명
8
배달 예정/도착/하차 완료
비스캣 → 오토메타
POST {콜백URL} (delivery.status_changed)
HMAC 서명
9
알림 노티 (신규)
비스캣 → 오토메타
POST {콜백URL} (notify.event)
HMAC 서명
10
박스 개폐 (하차) — 앱(WEB) 원격
오토메타 → 비스캣
POST /v1/automata/dispatch/{orderId}/unlock
API Key
URL 경로의 {orderId}는 오토메타가 발급한 전역 유니크 요청ID로, 후속 호출(#3·#4·#5·#10)·콜백(#6~#9)의 주키로 사용됩니다. 오토메타는 별도 robotId를 보관할 필요가 없습니다 — 배차 응답으로 내려가는 robotId는 표시·로그용 정보성 필드입니다.
#0 접속·인증 확인 — GET /v1/automata/ping
연동 초기·배포 후 자격증명(X-Api-Key-Id + X-Api-Key)과 연결을 자가 점검하는 부작용 없는 엔드포인트입니다(주문·미션을 만들지 않음).
200 응답이면 인증·연결 정상이며 { "result":"SUCCESS", "data":{ "keyId", "authenticated":true, "serverTime", "message" } }를 반환합니다.
401이면 헤더 누락 또는 키 불일치(발급 정보 재확인), 그 외 4xx/5xx·타임아웃이면 네트워크·엔드포인트 설정을 확인하세요.
운영에 영향이 없으므로 헬스체크·모니터링 프로브로도 사용할 수 있습니다.
3. 인바운드 (오토메타 → 비스캣)
POST /v1/automata/delivery/availability — #1 배송 가능 여부
shopId(매장, 필수)·dong·ho(세대, 필수)·boxCount(필요 박스 수, 필수)를 견적에 전달하면, 로봇이 점포·세대까지의 도착 예상시간을 합산한 etaMinutes를 산출하고 박스 수용 가능 여부까지 반영해 available을 판정합니다.
deliveryType이 trash_pickup(쓰레기 픽업)이어도 세대가 픽업 지점이므로 dong·ho는 동일하게 필수입니다.
견적도 배차(#2)와 동일하게 매장(shopId)·세대(dong·ho) 목적지 노드가 모두 매핑돼야 하며, 없으면 로봇 견적(offer) 전 422 DESTINATION_NOT_MATCHED로 거부됩니다.
요청
{
"deliveryType": "delivery|trash_pickup", // 구분 (매장/쓰레기)
"siteId": "APT-1023", // 단지코드
"shopId": "string", // 매장(점포) ID (필수)
"dong": "101", // 세대 동 (필수)
"ho": "1502", // 세대 호 (필수)
"boxCount": 2 // 필요한 박스 수 (1~4, 필수)
}
#6~#9는 비스캣이 오토메타 콜백 URL로 발신합니다. 공통 형식·서명·재시도를 따르며, X-Zeroworks-Event로 종류를 구분합니다.
콜백 요청 형식
POST {콜백URL}
Headers:
X-Zeroworks-Event: robot.shop_arrived | delivery.departed | delivery.status_changed | notify.event
X-Zeroworks-Signature: HMAC-SHA256(secret, body) // secret = 콘솔(서비스 설정)에서 발급받은 콜백 서명 키, 대상 = 요청 body 원문
X-Zeroworks-Timestamp: Unix timestamp (초 단위, 예: 1783644212)
X-Zeroworks-Delivery: uuid (재시도 시 동일 → 중복 수신 무시용 유니크 키)
서명 검증:secret은 콘솔(서비스 설정)에서 발급받은 콜백 서명 키입니다. 수신 시
HMAC-SHA256(secret, 수신 body 원문)을 계산해 X-Zeroworks-Signature와 일치하는지 확인하세요
(대상은 body 원문 그대로 — timestamp 등은 서명에 포함하지 않음. timestamp·delivery는 별도 헤더).