API 연동 견적을 요청하기 전에 데이터가 생성되고 최종 수정될 때까지의 업무 흐름을 설명하세요. “웹사이트와 ERP 연결”만으로는 대상 데이터, 전송 방향, 오류 처리 범위를 산정하기 어렵습니다.
시스템과 관리 주체를 정하세요
각 서비스의 이름, 요금제, API 문서와 업무 담당자를 정리합니다. 계약에 필요한 API 사용 권한이 포함되는지, 시험 환경이 있는지도 확인하세요. 일반 제안 요청 자료에 비밀번호나 운영 토큰을 넣지 말고 실제 구현 시 접근 절차를 정합니다.
데이터마다 기준이 되는 시스템을 지정해야 합니다. 상품 가용 수량은 ERP, 최초 주문 접수는 쇼핑몰이 담당할 수 있습니다. 필드별 관리 주체가 다르다면 이를 명시하세요. 양방향 연동에 충돌 규칙이 없으면 올바른 수정 내용을 덮어쓸 수 있습니다.
필드 매핑과 예시를 준비하세요
주문 연동 예시라면 외부 주문 ID, 주문 행 ID, 상품 코드, 수량, 단위, 통화, 상태, 시간을 대응시킵니다. 필수 여부, 허용값, 길이 제한과 빈값의 의미도 기록하세요. “알 수 없음”과 “기존 값 삭제”는 다른 요청입니다.
정상 주문, 부분 취소, 미등록 상품을 포함한 익명화 예시를 준비하면 필드 이름만으로 드러나지 않는 가정을 확인할 수 있습니다. 주문 수정 후에도 같은 거래를 식별할 수 있어야 합니다.
동기화 시점을 합의하세요
- 어떤 업무 이벤트에서 전송하나요?
- 수신 부서가 허용할 수 있는 지연은 얼마인가요?
- 수정·취소·삭제를 어떻게 표현하나요?
- 업데이트 순서가 바뀌면 어떻게 처리하나요?
- 호출 제한이나 정기 점검 시간이 있나요?
전달 방식과 제한은 제공업체의 최신 문서로 확인합니다. “즉시 반영”이라는 표현보다 측정 가능한 기준과 예외 보고 방법을 함께 정하는 편이 검수에 유용합니다.
복구 기능도 범위에 넣으세요
자동으로 다시 시도할 오류와 사람이 수정해야 하는 오류를 구분합니다. 같은 작업을 재전송해도 주문이 추가로 생성되지 않도록 원본 식별자와 중복 판단 규칙을 유지해야 합니다.
운영 담당자가 실패 기록, 이해할 수 있는 사유, 안전한 재실행 기능을 확인할 수 있게 합니다. 로그에는 필요한 참조와 상태를 남기고 민감한 본문을 불필요하게 복제하지 않습니다. 경고를 받고 조치할 팀도 지정하세요.
검수 시나리오 예시
- 정상 데이터가 올바른 대상에 한 번 등록됩니다.
- 필수값 누락이 확인 가능한 예외로 표시됩니다.
- 일시 중단 후 주문 중복 없이 복구됩니다.
- 나중에 들어온 취소가 합의한 규칙대로 반영됩니다.
- 대사 결과에서 누락과 불일치를 찾을 수 있습니다.