Google API 是什麼？地圖、雲端與辦公服務串接總覽指南

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

如果你最近正在規劃網站改版、開發一支 APP，或是想把公司內部的表單、報表串起來，多少會聽過「Google API」這個詞——通常是工程師或開發商在討論需求時提到的。聽起來有點技術，但概念其實不複雜，而且多數中小企業真正會用到的部分，門檻也沒有想像中高。這篇文章想用比較實際的角度，帶你搞懂 Google API 是什麼、常見會用在哪些情境、申請流程大致長怎樣，還有最容易讓人猶豫的部分——到底要不要花錢，以及容易被忽略的驗證與安全性眉角。

Google API 是什麼？先搞懂這座橋樑在做什麼

API（Application Programming Interface，應用程式介面）簡單說就是兩套系統之間溝通的規則。Google API，就是 Google 開放給開發者、網站經營者與企業系統的一整組介面，讓你的網站、APP 或後台系統，可以直接呼叫 Google 既有的服務——不用自己重新做一套地圖、重新做一套登入驗證、重新做一套數據分析工具。

換句話說，Google API 就是一座橋，橋的一端是你的網站或系統，另一端是 Google 已經做好、而且持續在維護的各種服務。你不用重新發明輪子，照規則把兩端接起來就好。

常被問到的一個問題是：「這是不是很技術性的東西，我一般業主也需要知道嗎？」實務上，你不一定要懂怎麼寫程式串接，但了解「這東西存在、什麼情況會用到、大概會不會花錢、有沒有隱藏的流程眉角」，對於跟開發商溝通需求、判斷報價與時程是否合理，會有實際幫助。

中小企業網站/APP最常碰到的四類 Google API

Google 提供的 API 種類其實非常多，但中小企業在做網站、APP 或系統開發時，真正常碰到的大致集中在四類，以下分別說明。

地圖類：Google Maps API，門市、店家、外送定位的常見選擇

如果你的網站需要顯示店家地址地圖、讓使用者輸入地址時自動跳出建議選項（地址自動完成）、或是需要計算兩點之間的距離與路線（例如外送、到府服務類的業務），通常就會用到 Google Maps 相關的 API，例如 Maps JavaScript API（顯示地圖本身）、Places API（地點搜尋與店家資訊）、Geocoding API（地址與座標互轉）。

這類 API 是中文搜尋結果中討論度最高的一塊，主要是因為 Google 在 2018 年開始針對地圖類服務收費，2025 年 3 月又進一步調整了計費規則（後面「費用眉角」段落會詳細說明），所以網路上關於「Google 地圖 API 到底要不要錢」的疑問特別多。

登入類：Google Sign-In，讓會員系統少一道註冊門檻

如果你的網站或 APP 有會員系統，應該看過「使用 Google 帳號登入」這個選項。這背後用的是 Google Sign-In（也就是 OAuth 2.0 授權機制的一種應用）——使用者不用重新填一次註冊表單、不用另外設一組密碼，直接用既有的 Google 帳號授權登入。

對業主來說，這類功能的價值主要在「降低註冊門檻、提高會員轉換率」，而不是省成本；對一般中小企業網站的日常登入用量而言，這類串接多半不會直接產生金錢費用（後面費用段落會說明依據）。不過這裡有一個常被忽略、但跟「收不收費」同樣重要的環節——應用程式驗證狀態，後面「申請流程」段落會特別說明。

數據分析類：Google Analytics 與 Search Console API，把後台報表接進自己系統

如果公司內部想把 Google Analytics（網站流量數據）或 Google Search Console（搜尋成效數據）的資料，直接拉進自己的後台系統或報表工具，而不是每次都手動登入 Google 介面查看，就會用到 Google Analytics Data API 或 Search Console API。

這類串接常見於已經有一定規模、需要跨多個數據來源整合分析的企業，例如同時管理多個網站、或需要把 SEO 成效數據跟業務系統的其他數據放在一起看。

辦公整合類：Sheets API 與 Forms API，把試算表當輕量資料庫用

不少中小企業在系統還沒完整導入前，習慣用 Google 試算表（Sheets）或表單（Forms）暫時管理資料——例如用試算表記錄訂單、用表單收集客戶資訊。Sheets API 可以讓你的網站或系統直接讀寫這份試算表的內容，等於把試算表當成一個簡易資料庫使用，這在系統開發初期、或預算有限想先做輕量版功能時，是常見的過渡方案。

Google API 申請流程：從 Cloud Console 到金鑰限制與驗證

不管是上面哪一類 API，申請流程的骨架大致相同：

1. 登入 Google 帳號，進入 Google Cloud Console（console.cloud.google.com）
2. 建立一個新專案（Project）
3. 到「API 和服務」頁面，搜尋並啟用你需要的特定 API（例如 Maps JavaScript API、Sheets API）
4. 建立憑證（Credentials）——單純資料查詢類的串接通常用 API 金鑰（API Key）；涉及使用者登入授權的則需要 OAuth 用戶端 ID
5. 設定金鑰限制——強烈建議限制可呼叫的 API 種類、限制網域或 IP 位址，避免金鑰外洩後被他人盜用
6. 若涉及可能超出免費額度而需要付費的 API，需綁定信用卡開通帳單帳戶
7. 若串接的是 OAuth 登入類服務，還需要額外留意「應用程式驗證」這一關

第 5 步的金鑰安全性，值得多花一點篇幅說明。Google Cloud 官方在多份安全性文件中都強調，未設定限制、直接曝露在網站前端程式碼中的 API 金鑰，是常見的資安風險來源之一——一旦被有心人士抓到，可能被拿去大量呼叫、產生非預期費用，甚至讓服務被鎖住。這不只是 Google 自家的建議，國際性的 API 安全風險框架 OWASP（開放網路應用程式安全計畫）在其 API 安全風險排行中，也把「驗證機制被破解」列為前段的重大風險項目，常見成因包括金鑰外洩、工作階段（session）管理不良、以及缺乏多重驗證機制——這說明「金鑰要設限制」不是 Google 一家之言，而是業界普遍認同的資安基本功。金鑰的取得與申請流程本身並不複雜，但金鑰管理這一步很容易被忽略，也是找專業開發商協助規劃時，價值比較容易被看見的地方。

第 7 步的應用程式驗證，是實務上最容易被低估工期的環節。如果你的網站或 APP 要串接的是 Google 登入這類需要使用者授權的功能，Google 官方文件明確說明：新建立的 OAuth 應用程式預設處於「未驗證」狀態，這個狀態下不論是測試階段或正式上線，使用者數量都會被限制在 100 人以內——也就是說，如果你的會員系統一旦要開放給超過 100 位真實使用者用 Google 帳號登入，就必須先把應用程式提交給 Google 審查、通過驗證後才能解除這個上限。依應用程式使用的授權範圍（scope）是否涉及敏感資料，驗證所需的準備與審查時間也不同，越涉及使用者隱私相關的敏感權限，審查通常越嚴謹。這一步跟「要不要花錢」是兩件不同的事——即使串接免費，若沒有提前規劃驗證流程，還是可能讓上線時程卡住，這也是為什麼建議在專案規劃初期，就先確認登入串接需求是否會用到需要驗證的授權範圍。

Google API 到底要不要錢？免費額度與收費眉角一次看懂

這大概是多數人最想知道，也最容易搞混的部分。先講結論：多數中小企業會用到的 Google API，在一般用量下屬於免費或幾乎不會產生費用，但不同 API 的免費門檻不一樣，而且 Google 的收費政策有調整過歷史，查到的資訊如果沒有標示查詢時間，很可能已經過時。

地圖類 API：2025年制度改版後，免費額度怎麼算

Google 地圖平台過去採用的是「每個計費帳戶每月 200 美元固定額度」，超過才開始收費——這也是早期多數中文教學文章描述的方式。但這個制度已經改變：依據 Google 官方定價頁（Google for Developers）公告，自 2025 年 3 月 1 日起，原本的每月 200 美元共用額度被取消，改為依服務類型（SKU）分級提供各自獨立的免費用量門檻：

• Essentials 類服務（如 Dynamic Maps 動態地圖、Static Maps 靜態地圖、Geocoding 地址轉換等）：每月 10,000 次免費事件
• Pro 類服務（如 Street View 街景、Place Details Pro 進階地點資訊等）：每月 5,000 次免費事件
• Enterprise 類服務（如 Photorealistic 3D Tiles、Fleet Routing 車隊路徑規劃等）：每月 1,000 次免費事件

有一個重點很容易被忽略：新制下，免費額度不再跨 API 互相流用——過去是一筆 200 美元的額度可以彈性用在任何服務上，現在則是每個 SKU 各自獨立計算，用完某一項的免費額度，即使其他項目還有剩，也不會互相補貼。超過免費額度後，依不同 SKU 與服務層級採階梯式計費（Google 官方定價清單顯示，各項服務每千次請求費率區間大致落在數美元到數十美元不等，實際費率請以 Google 官方定價頁面查詢當下數字為準，這是 Google 官方會持續調整的計價政策，本文不寫死絕對金額，避免資訊過時反而誤導讀者）。

對一般中小企業網站來說，如果只是嵌入一顆店家地圖、顯示地址、或做基本的地址自動完成功能，多數情境下用量還在免費門檻內；但如果應用場景涉及大量地點搜尋、路線規劃、或使用者流量本身就很大（例如外送平台等級的使用頻率），就比較可能觸及需要付費的用量。

登入、試算表、數據分析類：多數情境下不會產生費用

相較於地圖類 API，其他幾類中小企業常用的 Google API，費用結構相對單純：

• Google Sheets API：官方文件明確說明這項服務完全免費使用，超過配額限制不會產生額外費用，只會被限制請求速率（也就是說「配額」限制的是次數頻率，不是金錢）。
• Google Analytics Data API 與 Search Console API：同樣是免費使用，限制方式也是配額（例如 Search Console API 的資料匯出，每個網站每天有查詢筆數上限），一般中小企業日常報表串接的用量，通常遠低於這個上限。
• Google Sign-In（登入串接）：金鑰與 API 本身的申請免費，一般網站會員登入這類基礎功能，也不需要另外開通付費帳單即可使用。真正的限制不是金錢，而是前面提到的「應用程式驗證狀態」——Google 官方文件說明，OAuth 應用程式會依使用的授權範圍風險等級，套用新使用者授權速率限制，未驗證狀態下更有明確的使用者數量上限（100 人）。換句話說，登入串接「要不要花錢」跟「能不能立刻讓所有人用」，是兩個要分開確認的問題，不能只看免不免費就以為沒有其他門檻。

簡單說，「Google API 要收費」這件事，最主要集中在地圖類服務，而且是依用量分級計費、不是一申請就要付錢；其他幾類中小企業常用的 API，多數情境下停留在免費使用範圍，真正的門檻反而是「配額限制」與「應用程式驗證狀態」，而不是單純的金錢限制。

自己申請串接，還是找開發商協助規劃？

了解了申請流程跟費用結構之後，接下來很實際的一個問題是：這件事該自己來，還是找開發商？下面整理幾個判斷面向：

比較面向	自行申請與串接	委託開發商整體規劃
技術門檻	需要具備基礎程式與雲端主控台操作能力	由開發商完成規劃、串接與測試，業主端不需要自己動手
選型判斷	需自行判斷該用哪個 API、哪個計費層級適合自己的用量	由開發商依實際需求評估合適的 API 組合與預估用量
金鑰安全設定	需要自行了解限制設定，設定不當容易外洩被盜用	併入專案規劃，一併處理金鑰管理與限制設定
OAuth 驗證規劃	需自行留意是否會觸及 100 人未驗證上限、提前規劃驗證送審時程	併入專案時程一併評估，避免上線前才發現卡關
政策異動追蹤	若 Google 調整計費規則（如 2025 年地圖 API 制度改版），需自行留意並調整	屬於既有網站/系統維護服務範圍的一部分
適合情境	內部本身就有工程師、需求單純（如單純嵌入一顆地圖）	需求牽涉多個系統同時串接、需要整體評估、內部沒有工程資源

如果需求很單純——例如就是想在網站上放一顆店家地圖，內部剛好也有工程人力可以處理——自己申請串接完全可行，門檻不算高。但如果情況是像「新做一個網站，同時要有會員登入、店家地圖定位、後台還要串 GA 報表」這種多個系統同時要規劃的狀況，串接的複雜度會隨著串接數量疊加，這時候整體評估用量、選對 API 組合、規劃好金鑰管理與驗證時程，通常比逐一分開處理更有效率，也比較不容易漏掉安全性或驗證時程這類容易卡關的細節。

這也是瞻新資訊在「系統規劃開發」服務中會處理的一環——當專案本身就涉及進銷存、線上預約、CRM、O2O 媒合平台這類系統開發，過程中如果需要串接政府 Open API、金流服務或 Google 相關服務，這些串接需求會併入整體系統規劃一起評估，而不是等系統做完才回頭補接。跟多數技術規劃一樣，這裡沒有「保證最省錢」這種絕對化的說法——實際費用取決於用量與需求範圍，比較務實的做法是先把需求盤點清楚，再評估合適的串接方式與規劃順序，尤其是涉及使用者登入驗證的部分，提前確認是否需要走 Google 應用程式驗證，能避免上線前才發現時程被卡住。

FAQ

不管是自己動手還是找人協助，「先把需求想清楚」都是第一步——搞懂網站或系統實際會用到哪些 Google 服務、大概的使用量落在哪個範圍、是否涉及需要驗證的登入授權，才有辦法判斷後續該怎麼規劃，也比較不會被不必要的技術複雜度、收費疑慮或臨時卡關的審查流程打亂原本的上線時程。