공통 응답 형식: 성공·실패 모두 동일 형식 — { "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는 별도 헤더).
{
"code": "NOTI_ETA_5MIN", // 상태 식별자 코드만 전달
"orderId": "string", "robotId": "uuid",
"occurredAt": "2026-06-04T14:30:00+09:00"
} // 표출 문구는 오토메타가 관리
재시도 정책
2xx 응답을 받지 못하면 지수 백오프로 최대 24회/24시간 재시도.
각 시도는 동일 X-Zeroworks-Delivery ID — 오토메타는 이 ID로 중복 수신을 무시.
최종 실패는 비스캣 운영자 알림 + DLQ로 적재.
알림 코드 카탈로그
비스캣은 코드(상태 식별자)만 콜백으로 전달하고, 사용자 표출 문구·최종 표출 채널은 오토메타가 관리합니다. 아래는 콜백 발행 대상 코드입니다. 표출 채널·임계값(N·M분)·최종 코드명은 제안값이며 협의로 확정합니다.
코드
발생 시점
표출 채널(제안)
상태
NOTI_DISPATCHED
배차 확정(로봇 배정 완료)
주문자
NOTI_PICKED_UP
매장 상차 완료·배송 시작
주문자
NOTI_ETA_5MIN
하차지 도착 약 5분 전
주문자 · 세대
NOTI_ARRIVED
하차지(세대) 도착
주문자 · 세대
NOTI_DELIVERED
수령 완료
주문자
NOTI_PICKUP_REMINDER
도착 후 N분 미수령 — 재안내
주문자 · 세대
정책 협의 필요
NOTI_PICKUP_TIMEOUT
미수령 M분 초과 — 회수 전환
주문자 · 점주
정책 협의 및 로봇 개발 필요
NOTI_RETURNING
미수령 회수·복귀 시작
주문자 · 점주
정책 협의 및 로봇 개발 필요
NOTI_RETURNED
회수 완료
주문자 · 점주
정책 협의 및 로봇 개발 필요
NOTI_USER_CANCEL
사용자 주문 취소
주문자
NOTI_MISSION_EXPIRED
미션 만료
주문자 · 점주
정책 협의 및 로봇 개발 필요
NOTI_COLLISION
충돌 감지 — 지연 안내
주문자
NOTI_TRASH_ETA_5MIN
수거 로봇 도착 약 5분 전
세대
NOTI_TRASH_ARRIVED
수거 지점(세대 앞) 도착
세대
NOTI_TRASH_COLLECTED
배출물 수거 완료
세대
NOTI_TRASH_TIMEOUT
미배출 N분 경과
세대
정책 협의 필요
5. 에러 코드 (주문·배차 관련 발췌)
코드
HTTP
의미
AUTOMA_INVALID_PAYLOAD
422
배송/배차 페이로드 검증 실패
ORDER_DUPLICATE
409
동일 Idempotency-Key로 다른 페이로드
DISPATCH_LOAD_EXCEEDED
422
요청 박스 수(boxCount)가 적재함 4칸 초과 — 배차 거부
DESTINATION_NOT_MATCHED
422
주소 매핑에 매장(shopId)·세대(dong·ho)에 해당하는 목적지 노드 없음 — 배송 가능 여부(#1)·배차(#2) 공통, 로봇 견적·배차(offer) 전 거부
NO_ROBOT_AVAILABLE
503
디스패치 가능 로봇 없음 (정책상 거절). message 에 사유가 실린다 — 아래 5.1 참고
DISPATCH_NOT_FOUND
404
취소 대상 배차 없음
DISPATCH_NOT_CANCELABLE
409
출발 후 취소 불가
RATE_LIMIT_EXCEEDED
429
레이트 리밋 초과 — Retry-After 준수
5.1 NO_ROBOT_AVAILABLE 사유
HTTP 상태(503)와 result(NO_ROBOT_AVAILABLE)는 사유와 무관하게 동일하다.
구분이 필요하면 message 를 본다 — 아래 문구로 시작한다. 문구는 안내용이며 분기 조건으로 삼지 말 것
(신규 사유가 추가될 수 있다). 목록에 없는 사유는 입찰 가능한 로봇 없음 으로 떨어진다.
message 접두
뜻
파트너 측 대응
단지에 접속 중인 로봇이 없음
해당 단지에 온라인 로봇이 0대
재시도해도 같다. 운영 확인 필요
단지 로봇 전원이 비활성 상태(관제 운영자 조치)
관제 운영자가 해당 단지 로봇을 전부 비활성화한 상태. 로봇 장애·통신 문제가 아니다
파트너 측 조치는 없다. 관제에서 재활성화하면 즉시 해소되므로 비스캣에 문의
로봇 입찰 응답 없음
로봇이 모두 수행 중이거나 무응답
잠시 후 재시도
입찰 로봇 전원이 수행 불가로 응답
로봇이 무응답이 아니라 명시적으로 "못 한다" 고 답함(로봇 이상·배터리 부족 등)
잠시 후 재시도. 반복되면 운영 확인 필요
입찰 로봇 전원 적재함 만재
가용 로봇은 있으나 빈 칸이 없음
진행 중 배송이 끝난 뒤 재시도. 배송 가능 여부(#1)도 같은 기준으로 available:false 를 돌려준다