수신 서버가 받지 못했다고 할 때 원인을 가리는 데 써요. 성공·실패를 모두 남기기 때문에 "보냈는지 안 보냈는지" 부터 확인할 수 있어요.
요청 파라미터
| 파라미터 | 타입 | 필수 | 설명 |
|---|---|---|---|
page |
Integer | 선택 | 페이지 번호 (기본 1) |
limit |
Integer | 선택 | 페이지 크기 (기본 20, 최대 100) |
코드 예제
curl -X GET "https://message.bootapi.com/alimtalk/webhook/deliveries?limit=20" \
-H "Authorization: Basic {base64(client_key:secret_key)}"bashrequire 'bootpay'
commerce = BootpayStore::RestClient.new(client_key: 'your-commerce-client-key', secret_key: 'your-commerce-secret-key')
response = commerce.alimtalk_webhook_deliveries(limit: 20)
puts response.data[:list]ruby전송 상태 (status)
| 키 | 값 | 설명 |
|---|---|---|
done |
1 |
전송 성공 |
ready |
2 |
전송 대기 |
doing |
3 |
전송 중 |
failed |
-1 |
전송 실패 |
알려진 문제 — status 가 항상 ready 로 와요
지금은 전송이 성공하거나 실패해도 status 가 바뀌지 않고 "ready" 로 남아요. 성공한 전송은 더 이상 재시도하지 않아 retry_count 가 그 자리에 머무르고, 실패하면 재시도마다 늘어나요. 프로젝트의 가장 최근 전송 결과는 설정 조회의 last_status(HTTP 상태)·consecutive_failures 로 확인해요.
응답
최신순으로 내려와요.
{
"list": [
{
"delivery_id": "68b0f2a1c3d4e5f6a7b8c9e1",
"event": "alimtalk.send.succeeded",
"event_code": 301,
"url": "https://example.com/hooks/alimtalk",
"status": "ready",
"retry_count": 1,
"max_retry": 10,
"tags": ["68b0f2a1c3d4e5f6a7b8c9d0", "order-20260827-0001", "G_RESTOCK_NOTICE_user"],
"created_at": "2026-08-27T10:00:05+09:00"
}
],
"count": 1,
"page": 1,
"per": 20
}json| 필드 | 설명 |
|---|---|
| delivery_id | 전송 건 식별자 |
| event · event_code | 이벤트 별칭과 코드 |
| url | 전송한 수신 URL |
| status | 전송 상태 |
| retry_count · max_retry | 시도 횟수와 상한. retry_count 는 성공한 시도도 세서, 첫 시도에 성공하면 1 이에요. max_retry 는 그 건이 만들어질 때 설정의 retry_count 값이고, retry_count 가 여기에 이르면 더 보내지 않아요 |
| tags | 추적용 태그. 발송 건이면 receipt_id·ref_id·template_code, 테스트면 test |
created_at 의 형식은 응답의 시각 형식을 봐요.
태그로 특정 발송을 추적해요
tags 에 receipt_id 와 ref_id 가 들어 있어서, 어떤 발송 때문에 나간 웹훅인지 역으로 찾을 수 있어요.
재시도 중인지 확인해요
retry_count 가 1 을 넘어 계속 올라가고 있다면 수신 서버가 2xx 를 돌려주지 않고 있다는 뜻이에요. 연속 실패가 10회(기본값)에 이르면 웹훅이 자동 비활성화되니 설정 조회의 consecutive_failures·auto_disabled_at 도 함께 봐요.