Webhook Tester

훅이 삭제되었습니다. 이 URL은 더 이상 요청을 받지 않으며 캡처한 모든 내용이 사라졌습니다.

이 서비스가 저장하는 것 — 그리고 절대 하지 않는 것

훅을 만들면 SysOSX 체커 서버에는 훅 ID, 생성 및 만료 시각, 그리고 만든 주소만 저장됩니다. 캡처된 각 요청은 도착 시각, 메서드, 쿼리 문자열을 포함한 경로, 전송된 그대로의 헤더, 최대 256KB까지의 본문(그보다 길면 잘리고 표시됩니다), 그리고 발신자 주소를 저장합니다. 하나의 훅은 최대 50개의 요청을 보관하며, 그 이후의 전달은 만료될 때까지 거부됩니다. 모든 내용은 훅 생성 후 30분이 지나면 삭제되거나, 삭제 버튼을 누르면 즉시 삭제됩니다. 수신기는 받기만 합니다. 어떤 것도 가져오거나, 따라가거나, 재생하지 않습니다—캡처된 요청은 어떤 아웃바운드 호출도 일으키지 않습니다. 이웃한 디버깅 도구는 HTTP 상태 체인 추적기를, 전체 워크플로는 배관 작업 없이 Webhook 디버깅하기를 참고하세요.

수신기가 없으면 Webhook 디버깅이 번거로운 이유

Webhook은 다른 사람의 서버가 그들의 일정에 따라, 여러분이 통제할 수 없는 이벤트—결제 성공, 푸시 도착, 알림 발생—에 반응해 여러분의 서버를 호출하는 것입니다. 바로 이 형태가 Webhook 디버깅을 고통스럽게 만듭니다. 발신자는 여러분의 노트북에 닿을 수 없으므로, 실제 전달을 단 하나라도 보려면 로컬 개발에는 터널이나 공개 스테이징 머신이 필요합니다. 이벤트는 두 번 트리거하기 어려울 수 있으므로, 얻은 유일한 전달은 완전히 캡처되어야 합니다. 그리고 무언가 실패했을 때 발신자의 대시보드는 보통 엔드포인트가 반환한 상태 코드만 보여줄 뿐, 실제로 무엇을 보냈는지는 보여주지 않습니다. 서명 헤더가 있었나요? 본문이 문서가 약속한 JSON 형태였나요, 아니면 폼 인코딩이었나요? 재시도가 같은 이벤트 ID를 보냈나요? 핸들러가 기록하기 전에 요청을 거부했다면—Webhook 디버깅을 지배하는 서명 및 파싱 버그에서 정확히 그런 일이 일어납니다—이 질문들 중 어느 것에도 핸들러 로그만으로는 답할 수 없습니다.

임시 수신기는 그 순환에서 배관 작업을 제거합니다. 무엇이 도착하는지 보려고 반쯤 작성된 핸들러를 배포하는 대신, 모든 것을 받아들이고 충실히 기록하며 보여주는 주소를 만듭니다. 도착한 순서와 대소문자 그대로의 헤더, 어떤 파서도 거부할 기회를 갖기 전의 원시 본문, 발신자가 가끔 매개변수를 숨기는 쿼리 문자열, 그리고 정확한 메서드—일부 제공업체는 POST로, 일부는 PUT으로 전달하고, 몇몇은 GET으로 상태 확인을 하기 때문입니다. 실제 캡처된 전달 하나가 화면에 있으면 문서가 아니라 진실을 기준으로 핸들러를 작성할 수 있고, 실제 페이로드로 테스트 픽스처를 구축하며, 실패한 재시도와 원본을 나란히 비교할 수 있습니다. 그런 다음 훅을 삭제하고 제공업체를 실제 엔드포인트로 지정한 뒤 이벤트를 한 번 더 트리거하여 자체 핸들러가 응답하는 것을 지켜보세요. 30분은 의도적으로 짧습니다. 디버깅 세션에는 충분히 길고, 캡처된 페이로드로 가득 찬 잊힌 테스트 주소가 인터넷에 남아 있지 않을 만큼 짧습니다.

자주 묻는 질문