Connecting LINE to your CRM: webhooks, user IDs and consent

A customer sends your LINE Official Account a message. Seconds later it should appear on their record in your CRM, next to their previous bookings. That sounds simple, but three separate questions sit behind it: how does the message get from LINE to your system, how do you know which customer it belongs to, and are you allowed to keep it?

This guide answers each in plain language, so you can brief a developer and ask the right questions about security and privacy.

What happens when a customer messages your LINE OA

LINE does not wait for your system to ask for new messages. Instead, you give LINE the address of a webhook on your server. When something happens in your account, LINE sends a small data package, called an event, to that address.

A webhook event is like a delivery notice: it says what happened, who it came from and when. Your server reads the notice and decides what to do next. The Messaging API supports several event types. The ones most businesses care about are:

Event	What it means	What your system might do
Message	A customer sent text, an image, a sticker or other content	Log it, reply, or flag it for staff
Follow	Someone added your OA as a friend	Greet them, ask them to link their profile
Unfollow	Someone blocked or removed your OA	Stop messaging them, update the CRM
Postback	Someone tapped a button that sends hidden data	Continue a booking or menu step

The full list is in the LINE Developers documentation, and it grows over time, so ask your developer to build for the events you need and ignore the rest safely.

Verifying the webhook signature

Your webhook address is public, which means anyone could send fake events to it. LINE protects against this by adding a signature to every real request, generated from the raw request body with your channel secret. Your server must recompute the signature and compare it before it trusts anything in the request.

Skipping this step is one of the most common mistakes in rushed projects. Without it, someone who finds the address can create bookings, trigger replies or insert false data into your CRM. When you review a developer’s work, ask a direct question: “Do we verify the signature on every request, and what happens when it fails?”

Reply messages or push messages

Each message event comes with a one-time reply token. Your server can use it to answer that event, but only within a short window and only once. Check the current documentation for the exact limit rather than relying on memory.

Anything outside that window, such as a reminder the next morning, or anything you start yourself, goes out as a push message. The choice has practical effects:

• Replies suit direct answers: confirming a booking, returning an opening time, giving a status.
• Pushes suit scheduled and system-triggered messages, such as the appointment reminders that reduce no-shows, but count against your account’s messaging allowance.
• A slow server can miss the reply window, so keep the webhook quick: record the event, return a response, and do slower work such as CRM updates in the background.

Matching a LINE user ID to a CRM customer

Every event carries the LINE user ID, a long code that identifies one person. Two details catch many teams out.

First, it is not a phone number and does not tell you who the person is. Second, it is specific to your provider and channel. The same person has a different ID in another company’s LINE account, so you cannot import or look up IDs from elsewhere.

That means matching a LINE user to a CRM customer has to be a deliberate step. The common routes are:

1. A booking or registration form opened inside LINE through LIFF, where the customer enters a phone number or email and the system stores it with their LINE user ID. LIFF and how it differs from an OA or a MINI App is explained in LINE OA, LIFF or MINI App.
2. A one-time code sent to the phone number already in your CRM, entered in the chat.
3. Staff-assisted linking at the counter or on the phone, for example by scanning a QR code.

Whichever route you choose, decide what happens when a customer already exists under a different phone number. Without a rule, you will end up with duplicate customers, one from the walk-in booking and one from LINE. A matching key (usually a verified phone number) and a merge process for staff avoid most of this.

Consent and PDPA: what to tell customers

Thailand’s Personal Data Protection Act (PDPA) applies once you collect personal data, and a LINE conversation linked to a name, phone number or booking history is personal data. The points below are general information, not legal advice. Ask a qualified adviser to check your own wording.

• Privacy notice. Say what you collect, why, how long you keep it and who to contact. Link to it from the form where you collect the data.
• Purpose-specific consent. Consent to a booking reminder is not consent to marketing broadcasts. Ask separately and record each choice.
• Withdrawal. People must be able to withdraw consent as easily as they gave it. In practice, that means a clear way to say “stop” and a CRM that honours it.
• Retention. Decide in advance how long you keep each kind of data, and delete or anonymise it afterwards.

A practical design is to store a consent record for each customer: what they agreed to, the date and the wording they saw. When a rule changes, you can show what applied at the time.

Storing conversation history sensibly

It is tempting to save every message forever, because storage is cheap. It is not a good default. A chat history contains names, health details, complaints and photos that people shared in the moment. The more you keep, the more you must protect and disclose.

A sensible approach is to store what staff need to serve the customer: booking and order details, service notes and agreed follow-ups, plus recent messages for context. Keep sensitive content out of free text where you can, restrict who can see it, and set a retention period. The same principles apply when you point AI at this data, which we cover in using AI on company data safely under PDPA.

Common pitfalls to check for

• Unverified webhooks. Anyone can send fake events if the signature is not checked.
• Duplicate customers. No matching rule between LINE users and existing CRM records.
• Ignoring unfollow events. Reminders keep going to people who have left, and the CRM shows false reach.
• Lost events. The server is down or slow when LINE sends an event, and nothing retries or logs it.
• Storing everything forever. No retention period, no deletion process.
• One consent for everything. Marketing and service messages bundled together.

Next step: see how it works in a real product

If you want to see these ideas in a working system, our FoxConnect case study shows a booking and CRM platform that runs inside LINE. If your own CRM needs to connect, we can look at the events, matching rule and consent wording with you, and the extensions we build on FoxConnect show the kinds of integration that are possible.