IOSOR 가이드

첫 발송 전 웹훅 계약

Q: 서명된 URL과 소비처 소유권?

| 계약 필드 | 구매자가 주목하는 이유 | | --- | --- | | HTTPS 콜백 URL | 제품과 운영이 지정할 수 있는 단 하나의 목적지 | | 서명 비밀키 소유자 | 로테이션 담당자; 공유 채팅창에 절대 붙여넣지 않음 | | ACK 대 프로세스 규칙 | 먼저 영속화; ACK 이후 부수 효과 처리 | | 환경 분리 | 파일럿 URL ≠ 프로덕션 URL | | 알 수 없는 호스트 차단 | 스푸핑된 delivered 상태는 원장을 절대 갱신하지 않음 |

구매자 경로: 첫 선불 발송 전에 서명된 URL, 이벤트 유형, 멱등성 키에 합의하세요. 계약이 먼저고, 유료 트래픽은 그 다음입니다.

웹훅 계약 없는 선불 발송은 공유된 진실 없는 지출입니다. 재무팀이 상태와 원장이 맞지 않는 이유를 묻기 전에, 구매자는 첫 유료 메시지가 지갑을 떠나기 전에 서명된 URL, 이벤트 목록, 멱등성 키를 잠궈야 합니다. 이 페이지는 런칭 시 키 체크리스트나 서명 심층 분석이 아니라 구매자 경로를 다룹니다.

IOSOR는 화이트라벨 선불 시스템입니다. USD 20으로 하나의 회선에서 계약 파일럿을 자금 지원하고, 월 USD 1,000 부근의 소프트 리뷰는 «발송 먼저, 계약은 나중에» 방식을 기술 부채로 취급합니다. 클라이언트에게는 화이트라벨 이벤트 이름만 표시됩니다.

첫 유료 발송 전 계약 체결하기

유료 발송이란 지갑에서 차감이 가능하다는 뜻입니다. 계약이란 제품, 재무, 운영 부서가 콜백 도착 위치, 돈이나 상태 진실로 간주할 이벤트, 그리고 재시도를 안전하게 만드는 키를 이미 공유하고 있음을 의미합니다. 런칭 습관과 런웨이가 슬랙 스레드 상태인 채로 녹색으로 보일 수 있지만, 그것은 준비된 상태가 아닙니다. 런칭 시 웹훅과 키와 첫날 런웨이: 반드시 녹색여야 하는 것들을 참조하세요. 지난주 스테이징 콜백 URL로 트래픽을 구매하지 마세요.

서명된 URL과 소비처 소유권

계약 필드	구매자가 주목하는 이유
HTTPS 콜백 URL	제품과 운영이 지정할 수 있는 단 하나의 목적지
서명 비밀키 소유자	로테이션 담당자; 공유 채팅창에 절대 붙여넣지 않음
ACK 대 프로세스 규칙	먼저 영속화; ACK 이후 부수 효과 처리
환경 분리	파일럿 URL ≠ 프로덕션 URL
알 수 없는 호스트 차단	스푸핑된 delivered 상태는 원장을 절대 갱신하지 않음

소유자가 없는 서명된 URL은 새벽 2시가 되면 전설로 남게 됩니다. 월 USD 1,000 기준에서는 이러한 전설을 볼륨 리스크로 취급하며, USD 20은 하나의 URL, 하나의 소유자, 그리고 서명 미들웨어가 켜진 후에만 2xx를 반환하는 하나의 스모크 테스트를 증명합니다. 런칭을 버티는 웹훅 습관도 참조하세요.

제품과 재무가 공유하는 이벤트 유형

첫 발송 전에 자금이나 상태를 이동시킬 수 있는 이벤트를 나열하세요: accepted, delivered, failed, expired, 수신된 STOP, 그리고 진실로 취급하는 모든 검증 결과. 목록에 없는 이벤트는 차단되며 원장 행을 임의로 생성하지 않습니다. 공유 용어: 제품과 재무를 위한 공통 상태 언어. 선불 증명 없이는 홀드 상태도 여전히 차단됩니다 — 첫 차감 전 선불 잔액 예약. 계약은 이벤트 메뉴이며, 각 행의 신뢰 여부는 나중의 게이트가 결정합니다.

지출 전 멱등성 키

지출 전에 키 형태에 합의하세요: 플랫폼 이벤트 또는 메시지 ID, 부수 효과 전에 저장되며, 차감 행 옆에서 읽을 수 있어야 합니다. 타임스탬프와 바디를 조합하여 키를 즉석에서 만드는 방식은 재시도시 이중 과금을 유발합니다. 중복 이벤트 스모크 테스트가 단 하나의 원장 라인을 보여줄 때까지 소프트 볼륨 언어는 차단된 상태로 유지됩니다.

웹훅 계약을 위한 구매자 체크리스트

첫 유료 발송 전에 프로덕션 서명 URL이 지정되고 소유자가 지정되었나요?
제품과 재무가 공유하는 이벤트 목록이 구두가 아닌 문서로 작성되었나요?
부수 효과 전에 멱등성 키 모양에 합의하고 저장했나요?
파일럿과 프로덕션 소비자가 별도의 비밀키로 분리되었나요?
알 수 없거나 서명되지 않은 콜백이 정직한 상태로 차단되었나요?
계약이 초안 단계인 동안 월 USD 1,000 논의가 차단되었나요?

«아니오»가 하나라도 있다면 웹훅 계약과 유료 트래픽은 초안 상태로 남습니다.

IOSOR로 시작하기

유료 메시지 발송을 활성화하기 전에 IOSOR 콘솔에 접속하여 서명된 HTTPS 콜백 URL과 지정된 멱등성 키 필드를 함께 등록하십시오. 재시도가 단일 원장 행에 기록되는지 확인하여 트래픽 보류를 해제하기 전에 웹훅 게이트를 통해 무지출 중복 이벤트 페이로드 테스트를 실행하십시오.

IOSOR 핵심 요약

웹훅 계약은 비공식적인 조율이 아니라 재무와 제품 부서를 이중 출금 및 가상의 상태 업데이트로부터 보호하는 명확한 경계입니다. 첫 유료 전송 전에 서명 비밀 소유권, 정확한 URL 소유권, 그리고 엄격한 멱등성 키 구문 분석을 확립해야 재시도 폭풍으로 인해 원장 항목이 임의로 생성되는 것을 방지할 수 있습니다.

콜백 이벤트 목록을 고정하고 모든 수신 콜백에 대해 승인(ACK) 우선 사이드이펙트 아키텍처를 적용하십시오. 타임스몸이나 본문 해시에서 파생된 합성 키를 사용하여 라이브 프로덕션 트래픽을 시작하지 말고, 이벤트 상태 정의에 대해 구두 합의에 절대 의존하지 마십시오.

이 가이드가 도움이 되었나요?