SNS Webhook bypass (forwarding Webhooks from external SNS such as LINE)
For developers who want to receive Webhooks from external SNS such as LINE (message received, follow, postback, etc.) in their own app, via ReceiptRoller. It explains the mechanism and setup of the "SNS Webhook bypass" feature.
ReceiptRoller receives Webhooks sent from external SNS that a store has connected (LINE official account, Meta, X, etc.), and uses them for auto-replies and campaign processing. With the store's explicit permission, developers can have these raw events forwarded as-is to an endpoint they registered. This is the "SNS Webhook bypass".
When to use it
- You want to ingest LINE official account messages into your own CRM
- You want to trigger your own onboarding processing from a follow event
- You want to build your own rich-menu integration using postbacks
- You want to notify an internal tool of SNS mentions and replies
It is an option for cases that exceed what ReceiptRoller's built-in auto-reply feature can achieve and require your own business logic.
Mechanism
[LINE / Meta / X, etc.]
│ Webhook (with the platform-form signature)
▼
[ReceiptRoller receiving endpoint]
│ ① Verify the platform-form signature
│ ② ReceiptRoller's own processing (auto-reply, aggregation, etc.)
│ ③ If bypass is ON, forward to the developer endpoint
▼
[Developer app]
・You can tell the source SNS from X-RR-Source-Platform
・You can verify the original signature from X-RR-Original-Signature
・ReceiptRoller's signature is also attached via X-RR-Signature
ReceiptRoller "just relays" — the contents of the forwarded payload are the raw form from the SNS side, unchanged. For a LINE Webhook, LINE's JSON; for Meta, Meta's JSON, arrives as-is. This lets developers reuse each SNS's official SDK and documentation directly.
Setup (performed by the store administrator)
Bypass must be explicitly enabled on the store side. Developers should guide the store administrator through the steps on this page.
- Log in to the ReceiptRoller dashboard
- Left menu "Business account" → "SNS accounts"
- Open "Edit" on the relevant SNS account (e.g. LINE official account)
- Open the "Webhook bypass" section
- Toggle "Enable bypass" ON
- Select the developer app that is the forwarding destination (the app must be registered in advance)
- Select the event types to forward (e.g.
message,follow,postback) - Click "Save"
Headers on forwarding
| Header name | Contents |
|---|---|
X-RR-Source-Platform |
The source platform (line / meta / x / tiktok, etc.) |
X-RR-Source-Account-Id |
The SNS account ID inside ReceiptRoller |
X-RR-Original-Signature |
The original signature from the SNS side (e.g. for LINE, the value of x-line-signature) |
X-RR-Signature |
The HMAC-SHA256 signature attached by ReceiptRoller |
X-RR-Timestamp |
The forwarding time (Unix seconds) |
X-RR-Event-Id |
A unique event ID attached by ReceiptRoller (idempotency key) |
| Body | The raw payload from the SNS side (unmodified) |
Verifying the signature
On the receiving side, you can verify two kinds of signatures depending on your needs.
Method A: Verify ReceiptRoller's signature (recommended)
Verify X-RR-Signature the same way as a normal ReceiptRoller Webhook. Because you can unify the verification logic into one, operation is simpler. For details, see Signature verification and security.
Method B: Verify the original SNS signature
Because the body is the raw form from the SNS side, you can also use each SNS's SDK to verify the original signature (X-RR-Original-Signature). This is convenient when you want to reuse the LINE official SDK's sample code as-is. In that case, however, the developer needs to hold the SNS-side channel secret.
Receiving example (LINE)
POST /your/endpoint HTTP/1.1
Content-Type: application/json
X-RR-Source-Platform: line
X-RR-Source-Account-Id: sns_a1b2c3
X-RR-Original-Signature: aXyZ... (the signature issued by LINE)
X-RR-Signature: 9f8e7d... (the HMAC issued by RR)
X-RR-Timestamp: 1745740000
X-RR-Event-Id: evt_01HV6N...
{
"destination": "U1234567890...",
"events": [
{
"type": "message",
"message": { "type": "text", "id": "...", "text": "Hello" },
"timestamp": 1745739999000,
"source": { "type": "user", "userId": "U..." },
"replyToken": "..."
}
]
}
Because the body is exactly what was received from LINE, you can pass it as-is to the LINE Messaging API SDK's WebhookParser, etc.
Notes on replying
With bypass, the developer endpoint only needs to return 2xx; send reply messages and the like by calling the SNS API directly from the developer side. ReceiptRoller does not relay responses.
- If you use LINE's
replyToken, the developer POSTs directly to the LINE Messaging API - For that, you need to separately handle the store's LINE channel access token
- How you obtain it is arranged per store (a platform-form authorization flow, or manual sharing from the store)
Resend and idempotency
Forwarded events, like normal Webhooks, are resent up to 7 times if the response is not 2xx. Be sure to implement an idempotency check using event_id. For details, see Designing resends, ordering, and idempotency.
Note that even if the original SNS Webhook has already been processed by another channel (such as the auto-reply processing) first, bypass is forwarded independently. Design the two separately.
Limitations
- Supported platforms: LINE, Meta (Facebook/Instagram), X, TikTok, YouTube, Pinterest, LinkedIn, GBP (expanding progressively)
- Up to one forwarding-destination app per SNS account
- Only events that occur on the SNS side are forwarded. ReceiptRoller's own events are not included
- Bypass is available on the Starter plan or higher
- The forwarding delay is normally within 1 second (after receiving from the platform)
Security and privacy notes
- The forwarded body contains personal information such as the LINE user ID and message text
- The store's privacy policy needs to state the forwarding to the external developer
- The developer side, too, should clarify the retention and use scope of the received data in a contract with the store
- For testing, use a dedicated test SNS account and avoid handling real customer data
Related guides
-
Receive new sales by webhook and post them to SlackRegister a receipt.created webhook, verify its signature and drop duplicates in Node.js, and post each new sale to a Slack channel.
-
Designing resends, ordering, and idempotencyWhat counts as success, the retry rules (1 min, 10 min, 1 h, four attempts), ordering and lost events, and dropping duplicates by X-RR-Delivery.
-
How to register a WebhookRegister a webhook in the developer portal or through the API, choose events that are actually sent, run a test send, and change, pause or delete a webhook.
-
Webhook is not being deliveredWhen a webhook does not arrive: narrow it down with a test send and the delivery log, then check the active flag, subscribed events, connection and signature.
-
Developer Help IndexThe index of ReceiptRoller developer help. Covers the developer application, app registration, OAuth authentication and scopes, implementation guides (wallet apps, store-facing Webhooks, the Survey API), guides by data domain, operations and security, the community, and troubleshooting.