LINE Developer 開發者平台註冊與 API 串接：Messaging API 與 LIFF 應用設定步驟

開頭隨便記一下

今天來快速記一下怎麼在 LINE Developer 平台上弄東西。很多人搞不清楚，其實邏輯很簡單。你要先有一個「公司」或「團隊」的身份，這個在 LINE 裡面叫做 `Provider`。然後在這個 `Provider` 底下，再去開你需要的功能頻道，比如要做聊天機器人，就開 `Messaging API Channel`；要做內嵌在 LINE 裡面的網頁，就開 `LIFF` 應用。結構大概就是 `Developer` (你的帳號) -> `Provider` (你的公司/品牌) -> `Channel` (你的機器人或應用)。

老實說，官網文件寫得很詳細，但有時候介面改來改去，或是有些地方卡住會不知道為什麼。還有，最近（2024年9月）建立 Messaging API 的流程有變，變成要從另一個統一的入口去建立，這點要注意。總之，目標是把一個 Bot 跟一個 LIFF App 串起來。

怎麼做？步驟與要點

好了，直接開始。邊想邊記。

第一步：登入然後建立 Provider

這步很直覺。去 LINE Developers Console，用你的 LINE 帳號登入。登入後，應該會看到一個大大的按鈕叫你 `Create a new provider`。這個 Provider 就是你所有服務的家，可以想成是公司名稱。名字取好，以後要改也可以，但一開始就想好比較省事。一個開發者帳號可以有好幾個 Provider。

第二步：建立 Messaging API Channel

Provider 蓋好之後，就要在裡面蓋房間了。第一個房間是 `Messaging API`，也就是聊天機器人的本體。

在 Provider 裡面，選 `Create a Messaging API channel`。
接著會被引導到建立 LINE 官方帳號 (LINE Official Account) 的頁面，因為現在這兩者是綁在一起的。
填一些基本資料：帳號名稱（這就是使用者看到的 Bot 名字）、業種、Email 等等。這些之後大多可以改。
建立完成後，最關鍵的東西就在 `Channel settings` 裡面了。

有兩個東西一定要記下來，等一下馬上要用：

Channel secret：在 `Basic settings` 頁籤底下，這像是你的密碼，用來驗證從 LINE 平台來的請求是不是合法的。
Channel access token (long-lived)：在 `Messaging API` 頁籤底下，這個是你用來主動發訊息給用戶的鑰匙。點一下 `Issue` 按鈕就會產生一長串字。這個 token 有效期很長，除非自己重設，不然不會變。

第三步：設定 Webhook URL (超重要)

Webhook... 簡單講，就是你跟 LINE 說：「欸，如果有人傳訊息給我的 Bot，請你把訊息內容『丟』到我這個網址。」這個網址就是 Webhook URL。

你的伺服器必須要有一個公開的、`HTTPS` 的網址。
把這個網址填到 `Messaging API` 頁籤的 `Webhook settings` 裡。
最容易卡關的地方：填完網址後，要按旁邊的 `Verify` 按鈕。 LINE 會馬上送一個測試的 `POST` 請求到你的網址。如果你的伺服器沒有正確回應，就會顯示失敗。所以你的後端程式要先準備好接收這個驗證請求。
記得要把 `Use webhook` 這個開關打開。不然就算設定了，LINE 也不會鳥你，只會用預設的自動回應。

我看到有台灣的開發者分享用 `fastapi-linebot` 搭配 Cloudflare Tunnel 快速建立 webhook，這樣就不用自己煩惱 HTTPS 憑證，這對初期測試來說真的超方便。這跟 LINE 官方主要推的 SDK 文件是不同思路，但很實用。

第四步：來弄個 LIFF 應用

LIFF，全名是 LINE Front-end Framework。想像成 LINE App 裡面的內建小瀏覽器，但這個瀏覽器很厲害，可以拿到用戶的 LINE 資料（當然要經過用戶同意）。

建立 LIFF 應用很有趣，它不是一個獨立的 Channel。你得先進到一個 `LINE Login` 類型的 Channel，然後在裡面的 `LIFF` 頁籤新增。
如果一開始只有建 Messaging API channel，它其實背後也幫你弄好了一個 LINE Login 的功能。所以，直接在你的 Messaging API Channel 設定裡，找到 `LIFF` 頁籤，點 `Add` 就對了。
LIFF app name：這個名字只會顯示在後台，方便你自己辨識。
Size：LIFF 視窗的大小，有 `Full (100%)`、`Tall (70%)`、`Compact (50%)` 三種。通常選 `Full` 體驗最好。
Endpoint URL：這就是你的網頁網址。使用者在 LINE 裡面點開這個 LIFF 連結，看到的就是這個網址的內容。
Scopes：這是重點。你要跟使用者要什麼權限。`profile` 可以拿到使用者的名稱跟大頭貼，`openid` 可以拿到一個獨一無二的 ID。如果你的 LIFF App 需要幫使用者發訊息，還要勾選 `chat_message.write`。
設定好之後，你會得到一組 `LIFF ID` 跟一個 `LIFF URL`（格式是 `https://liff.line.me/...`）。在你的網頁裡，就是用這個 `LIFF ID` 去初始化 LIFF SDK。

所以，Messaging API 跟 LIFF 差在哪？

剛開始真的會搞混。用個比喻，`Messaging API` 比較像「傳單」，你可以主動推播訊息給所有好友，或是做一對一的客服問答。它是以「訊息」為核心。而 `LIFF` 則像是在 LINE 裡面開了一間「快閃店」，是一個完整的網頁，使用者可以進來逛、填表單、玩遊戲，互動體驗更豐富。

老實說，我自己是覺得，兩者結合起來威力最大。例如用 Messaging API 推一個活動訊息，裡面放一個 LIFF 連結，使用者點進去直接在 LIFF 頁面報名。因為 LIFF 可以自動取得使用者資料，連登入都省了，體驗超流暢。

Messaging API vs. LIFF 快速比較筆記
項目	Messaging API (訊息機器人)	LIFF (內嵌網頁)
核心概念	以「訊息」為單位，一來一往的對話。	一個完整的「網頁應用」，跑在 LINE 裡面。
主要用途	發送推播、自動客服問答、關鍵字回應。	複雜的表單、會員註冊、小遊戲、預約系統。
使用者介面	受限於 LINE 的訊息格式，像 Quick Reply、Flex Message。	完全自由，就是你寫的 HTML/CSS/JS。
開發技能	主要是後端開發（接收 Webhook、呼叫 API）。	主要是前端開發（JavaScript、React/Vue），加上一點後端。
怎麼觸發？	使用者傳訊息給你的官方帳號。	使用者點擊一個 LIFF URL 連結 (liff.line.me/...)。
個人筆記	適合做「通知」跟「簡單引導」。成本低，快速。	適合做需要「沉浸式體驗」的服務。開發比較花時間，但能做的事多太多了。

一些容易卡關的點（踩雷心得）

Webhook 驗證失敗：90% 的可能是你的後端服務沒跑起來、URL 打錯，或是沒有正確處理 LINE 送來的驗證請求。可以先用 ngrok 之類的工具在本機測試，比較好除錯。
LIFF 頁面一片空白：最常見的是 Endpoint URL 設錯，或是你的網站有 Content Security Policy (CSP) 擋掉了來自 line.me 的 frame。另外，LIFF ID 初始化失敗也可能造成。打開瀏覽器的開發者工具看 Console 錯誤訊息是你的好朋友。
權限 (Scope) 忘了勾：在 LIFF 裡呼叫 `liff.getProfile()` 失敗？八成是建立 LIFF App 時忘了勾 `profile` 這個 scope。回去 Console 補勾一下就好。
CORS 跨域問題：你的 LIFF 網頁如果要從前端呼叫你自己的 API，後端 API 伺服器記得要設定 CORS (Cross-Origin Resource Sharing)，允許來自 `liff.line.me` 或你網頁源的請求。

總之，開發者後台的設定看起來很多，但只要把 Provider 和 Channel 的關係搞懂，然後分清楚 Messaging API 和 LIFF 的用途，基本上就不會迷路了。