요구 사항
이벤트를 보내기 전에 다음을 확인하세요:- 액세스를 위해 영업팀에 문의합니다.
- URL/IP 주소가 유효하고 HTTP 또는 HTTPS를 통해 연결할 수 있습니다.
- 엔드포인트가 공개적으로 라우팅 가능합니다(즉, 방화벽 뒤나 localhost에 있지 않음).
- 도메인에 유효한 최상위 도메인이 있어야 합니다(예:
.com,.org,.net). - Journey Webhook은 OneSignal API를 호출하는 데 사용할 수 없습니다.
설정
Journey가 생성되면 다음 단계를 따릅니다:- OneSignal 대시보드에서 데이터 > Webhook으로 이동합니다.
- 클릭하여 새 Webhook을 생성합니다.
- 다음을 정의합니다:
- HTTP 메서드(일반적으로
POST) - 타겟 URL
- 커스텀 헤더(예: 인증용)
- 본문 콘텐츠(일반 텍스트 또는 JSON, 선택적으로 Liquid 사용)
- HTTP 메서드(일반적으로

Webhook 구성 화면
허용되지 않는 헤더
다음 헤더는 설정할 수 없습니다:content-lengthreferermetadata-flavorx-google-metadata-requesthostx-onesignal로 시작하는 모든 헤더
Webhook 테스트
curl과 같은 도구를 사용하여 엔드포인트를 수동으로 테스트할 수도 있습니다:bash
개인화
모든 Webhook 필드는 Liquid 구문을 지원하므로 사용자 및 구독 데이터를 요청에 동적으로 삽입할 수 있습니다. 예시 본문: 자세한 내용은 Liquid 구문 사용 가이드를 참조하세요.
사용자 데이터 참조
Liquid 구문을 통해 Webhook 필드에서user 객체의 다음 속성을 사용할 수 있습니다:
| 속성 | 타입 | 사용법 | 테스트에서 사용 가능? |
|---|---|---|---|
| OneSignal ID | String | {{ user.onesignal_id }} | ✅ |
| External ID | String | {{ user.external_id }} | ✅ |
| Tags | Object | {{ user.tags.your_tag_key_here }} | ❌ |
| Language | String | {{ user.language }} | ✅ |
활성 Journey 외부에서 Webhook을 테스트할 때는 태그를 사용할 수 없습니다. 라이브로 전환하기 전에 테스트 구독을 사용하여 동작을 확인하세요.
Journey에 Webhook 추가
- Webhook을 생성하고 테스트한 후 Journey를 엽니다.
- 필요한 곳에 Webhook 단계를 추가합니다.
- 이전에 구성한 Webhook을 선택합니다.

Journey 내의 Webhook 단계
디버깅 및 로그
Webhook 통계
Webhook의 통계 탭으로 이동하여 Webhook의 성능을 확인합니다. 여기에는 다음이 포함됩니다:- 총 전송 이벤트
- 응답 시간 추세
- 상태 코드 분포

Webhook 보고서 페이지
로그 탭
더 세부적인 통찰력을 위해 로그 탭에 다음이 표시됩니다:- 최근 요청/응답 데이터
- 상태 코드 및 오류 메시지
- 헤더 및 페이로드(해당하는 경우)

Webhook 로그 페이지
재시도 로직 및 비활성화 동작
OneSignal은 복구 가능한 오류(예:429 Too Many Requests)에 대해 실패한 Webhook 요청을 재시도합니다. 재시도는 지연 시간이 증가하면서 발생합니다.
재시도가 반복적으로 실패하면 Webhook이 영구적으로 실패로 표시되고 더 이상 시도하지 않습니다.
자동 비활성화
Webhook이 지속적으로 실패하면 OneSignal은 추가 문제를 방지하기 위해 비활성화합니다. 관리자는 Webhook이 비활성화되기 전과 후에 이메일 알림과 대시보드 배너를 받습니다. 이런 경우 Webhook을 다시 활성화하기 전에 문제 해결, 수정 및 테스트를 하는 데 시간을 할애해야 합니다. Webhook을 수집하는 API가 메시지 전송으로 생성된 이벤트 볼륨을 처리할 수 있는 것이 중요합니다. 앱에서 생성된 메시지 전송 볼륨을 검토하면 API에 필요한 성능이 반영됩니다.성능 가이드
- 느리거나 과부하된 엔드포인트(특히 429 응답)는 비활성화를 트리거할 수 있습니다.
- API는 이벤트를 빠르게 기록하고 타임아웃을 방지하기 위해 추가 처리를 연기해야 합니다.
- 볼륨은 사용자 활동에 따라 확장되므로 엔드포인트가 이 처리량을 처리할 수 있는지 확인하세요.
event.id값(헤더 또는 본문에서 사용 가능)을 사용하여 들어오는 이벤트를 중복 제거합니다.
성공을 위한 팁
- 타사 서비스에 직접 연결하지 말고 먼저 자체 서버에 Webhook을 연결합니다.
- OneSignal Webhook은 공개 API를 호출할 수 있지만 자체 서버를 통해 라우팅하면 더 많은 제어 권한을 얻을 수 있습니다.
- 디버그, 로깅 추가, 인증 처리 및 필요에 따라 요청 조절 또는 대기열이 더 쉽습니다.
- 타사 서비스는 볼륨이 급증하면 요청을 속도 제한하거나 차단할 수 있으며 OneSignal은 이러한 제한을 관리하지 않습니다.
- Webhook 실행은 사용자가 Journey에서 해당 단계에 도달하는 즉시 발생합니다.
- 많은 사용자가 한 번에 Webhook 단계에 도달하면 OneSignal은 속도 제한 없이 HTTP 요청을 대량으로 보냅니다.
- 이로 인해 외부 서비스를 쉽게 압도하고 속도 제한을 트리거하거나 예상치 못한 요금이 발생할 수 있습니다.
- 다음을 수행할 수 있는 경량 API 레이어 또는 대기열 프록시를 구축하는 것을 고려하세요:
- Webhook을 안정적으로 수집
- 속도 제한 또는 일괄 처리 적용
- 요청을 타사 서비스로 우아하게 라우팅
- 타사 API를 신중하게 사용하세요:
- 대부분의 인기 도구(예: Slack, Twilio, Segment)는 공개 HTTP API를 제공합니다.
- 속도 제한, 인증 요구 사항 및 오류 처리 전략을 검토하세요.
- 해당 문서에서 코드 예제를 검색하여 Webhook 요청이 어떻게 보이는지 확인하세요.
Webhook 보안
요청이 OneSignal에서 오고 변조되지 않았는지 확인하려면:- 공유 비밀이 있는 HMAC 서명 헤더 사용
- 헤더에 커스텀 인증 토큰을 추가하고 서버 측에서 확인