대시보드
총 잔액 (하부+유저)
—
—
하부 매장 총잔액
—
하부 유저 총잔액
—
전체 영업하부 수
—
전체 운영매장 수
—
전체 사용자
—
총 파이널칩 잔액
—
진행중 hold
—
활성 세션
—
오늘 로그인 활동
| 아이디 | 닉네임 | 역할 | 세션수 | 마지막 |
|---|
현재 진행 중 베팅
| 아이디 | 테이블 | 금액 | 시작 |
|---|
공지사항
실시간 접속 현황
| 아이디 | 닉네임 | 역할 | 로그인 | 마지막 활동 | 만료 |
|---|
실시간 배팅 현황
| betting_id | 아이디 | 테이블 | game | 스테이크 | hold | before | after_hold | 시작 |
|---|
에이전시 트리
하위 조직 트리 — 노드별 잔액
하부 계정 생성
새 계정 생성
현재 계정의 한 단계 아래 계정만 생성할 수 있습니다.
마이 프로필
기본 정보
아이디
—
계층
—
요율
—
가입일
—
닉네임 / 비밀번호 변경
API 키
외부 시스템에서 X-API-Key 또는 Authorization: Bearer <key> 헤더로 호출 시 사용. 화이트리스트 비어 있으면 키만으로 통과.
IP 화이트리스트
한 줄에 하나씩. IP (예: 1.2.3.4) 또는 CIDR (예: 10.0.0.0/24). 비우면 IP 검사 안 함.
사용자 관리
유저 생성
사용자 목록
| id | 아이디 | 닉네임 | 역할 | 아너링크 | 파이널 | 가입일 |
|---|
파이널칩 잔액
| 아이디 | 잔액 | holding | 통화 | 최종업데이트 |
|---|
머니 지급 · 회수
아너링크 잔액 조정
파이널칩 잔액 조정
파트너 관리
파트너 계층 구조 미정의. users 테이블에 partner_code / parent_id 컬럼과 파트너 정의 테이블이 필요합니다.
거래 로그
| id | 아이디 | action | delta | before | after | hold↕ | betting_id | 시각 |
|---|
통합 배팅 내역
| 구분 | ref_id | 아이디 | game | table | type/상태 | 금액 | payout | net | 시각 |
|---|
로그인 이력
| 아이디 | 닉네임 | 역할 | 오늘 세션수 | 첫로그인 | 마지막 |
|---|
아너링크 트랜잭션
| tx_id | 아이디 | 유형 | 금액 | 잔액후 | 출처 | 비고 | 시각 |
|---|
API 연동 매뉴얼
기본 정보
베이스 URL
—인증
X-API-Key · Bearer콘텐츠 타입
application/json에러 포맷
{ "error": "메시지" }인증 방식 (외부 API 호출용)
1. X-API-Key (매장 전용 · 권장)
매장 계정에 발급된 키를
X-API-Key: <key> 헤더로 전달. 마이 프로필 → API 키 에서 확인/재발급. IP 화이트리스트 채워져 있으면 요청 IP 일치해야 함.curl -H "X-API-Key: 2thfF1pu1V2SJdy5..." \
https://<host>/api/admin/my-profile
2. Authorization: Bearer (호환)
매장 API 키를
Authorization: Bearer <key> 형태로도 받음. 또는 환경변수 BACKOFFICE_API_KEY 가 설정된 경우 본사(hq) 권한으로 통과.curl -H "Authorization: Bearer 2thfF1pu1V2SJdy5..." \
https://<host>/api/admin/my-profile
시작하기 — 5분 안에 첫 호출
- API 키 발급 — 본 어드민에 매장 계정으로 로그인 → 마이 프로필 → API 키 의 키를 복사. (없으면 재발급 버튼 클릭)
- IP 화이트리스트 (선택) — 외부 호출 서버의 공인 IP 를 마이 프로필 → IP 화이트리스트에 등록. 비워두면 키만으로 통과 (테스트에 편함, 운영엔 비권장)
-
본인 정보 확인 — 연결 검증용 첫 호출.
GET /api/admin/my-profile가 200 + 본인 매장 정보 반환하면 인증 성공curl -H "X-API-Key: $KEY" https://<host>/api/admin/my-profile
-
회원 생성 —
POST /api/admin/create-child로 매장 밑에 회원 등록. 이 회원이 베팅 주체 -
잔액 지급 —
POST /api/admin/adjust-final-balance로 회원 파이널칩 잔액에 입금.direction: credit은 지급,debit은 회수 -
잔액/베팅 조회 —
GET /api/admin/wallets로 회원 지갑 현재 잔액 확인.GET /api/admin/unified-betting-history로 베팅/정산 내역 확인
파이널 지갑 연동 흐름 (전체 시퀀스)
외부 시스템 (매장 사이트, 회원 관리 백오피스) 에서 파이널 지갑을 다루는 표준 흐름. 모든 호출은 매장 X-API-Key 로 인증.
A
회원 등록 (1회)
POST /api/admin/create-child
매장이 자기 밑에 회원 1명 생성.
username, nickname, password 만 보내면 됨 (role 은 자동 = member, 요율은 매장 본인 요율 자동 상속).B
잔액 충전
POST /api/admin/adjust-final-balance · {"username":"u1","amount":10000,"direction":"credit"}
매장에서 회원 사이트의 머니로 결제 받으면 그 만큼 파이널칩으로 충전. 응답에 충전 후 잔액 포함.
C
게임 입장
회원이 이 포털 도메인의
/launch/one-click (브라우저) 로 진입 — 또는 자체 도메인에서 iframe 으로 embed. 베팅/정산은 evosrv 프록시가 자동 처리.D
베팅 자동 처리 (서버 측)
회원이 게임에서 베팅 → evosrv 가 가로채
ubalance.balance_amount 차감, history 에 holding 행 생성 → 라운드 종료 시 자동 settle → 잔액 변동 반영. 외부 호출 불필요.E
실시간 모니터링 (선택)
GET /api/admin/active-bets · GET /api/admin/active-sessions
진행 중 베팅 (holding) 과 접속 중 회원 폴링. 1초 간격 권장.
F
잔액 조회 / 출금
GET /api/admin/wallets → POST /api/admin/adjust-final-balance · {"direction":"debit"}
회원이 출금 요청 시 매장 시스템이 잔액 확인 → debit 으로 회수 → 자체 시스템 머니로 정산.
G
정산 내역 추적
GET /api/admin/unified-betting-history?username=u1&limit=300
아너링크 트랜잭션 + 파이널 history 통합 시간순. 매일 batch 로 받아 회원 손익 정산.
공통 에러 응답
| HTTP | 의미 | 가능한 원인 | 대응 |
|---|---|---|---|
| 400 | BAD_REQUEST | 필수 필드 누락, 형식 오류, 검증 실패 | 응답 error 메시지 확인 후 페이로드 수정 |
| 401 | UNAUTHORIZED | API 키 없음 / 잘못된 키 / 만료된 세션 | 유효한 X-API-Key 헤더 첨부 |
| 403 | FORBIDDEN | 요청 IP 가 화이트리스트 밖, 권한 없는 리소스 접근 | 마이 프로필 → IP 화이트리스트 확인 |
| 404 | NOT_FOUND | 존재하지 않는 사용자/리소스 | username/id 재확인 |
| 409 | CONFLICT | 중복 (이미 사용 중 아이디) | 다른 username 으로 재시도 |
| 5xx | SERVER_ERROR | 내부 오류 / 업스트림 (HonorLink) 장애 | 잠시 후 재시도, 지속 시 운영팀 문의 |
API 연결 테스트
요청 구성
응답
결과가 여기에 표시됩니다.