第三方 API

Google Ads 指令碼的一項強大功能是整合第三方 API 的資料和服務。

本指南會說明下列概念，協助您編寫指令碼，以連線至其他服務：

• 提出 HTTP 要求：如何使用 UrlFetchApp 存取外部 API。
• 驗證：我們會說明一些常見的驗證情境。
• 剖析回應：如何處理傳回的 JSON 和 XML 資料。

注意： 撰寫或使用第三方 API 的指令碼時，建議您詳閱該 API 的相關條款及細則，確保用途符合相關規定。

使用 UrlFetchApp 擷取資料

UrlFetchApp 提供與第三方 API 互動所需的核心功能。

注意： UrlFetchApp 是與第三方 API 互動的基本要素，不過在開發解決方案時，應留意用途的配額。

以下範例顯示如何從 OpenWeatherMap 擷取天氣資料。我們選擇 OpenWeatherMap 因為這個方式比較簡單的授權配置和 API

提出要求

OpenWeatherMap 說明文件會指定要求目前天氣的格式，如下所示：

http://api.openweathermap.org/data/2.5/weather?q=[location]&apikey=[apikey]

網址提供第一個授權範例：apikey 是必要參數，且每個使用者都有專屬的值。這個金鑰的取得方式為註冊。

註冊後，使用金鑰的要求可以按照下列方式發出：

const location = 'London,uk';
const apikey = 'da.......................81'; // Replace with your API key
const currentWeatherUrl = `http://api.openweathermap.org/data/2.5/weather?q=${location}&apiKey=${apiKey}`;
const response = UrlFetchApp.fetch(currentWeatherUrl);
console.log(response.getContentText());

執行這段程式碼會導致系統將一長串 JSON 文字寫入 Google Ads 指令碼的記錄視窗，

下一步是將此格式轉換成可在指令碼中使用的格式。

JSON 資料

許多 API 會以 JSON 格式提供回應。這代表了 JavaScript 物件的簡易序列化作業，例如物件、陣列和基本類型，能以字串表示及轉移。

如要將 JSON 字串 (例如 OpenWeatherMap 傳回的字串) 轉換為 JavaScript 物件，請使用內建的 JSON.parse 方法。延續上例：

const json = response.getContentText();
const weatherData = JSON.parse(json);
console.log(weatherData.name);
//  "London"

JSON.parse 方法會將字串轉換為具有 name 屬性的物件。

如要進一步瞭解如何使用不同格式的 API 回應，請參閱「剖析回應」。

處理錯誤

在指令碼中使用第三方 API 時，錯誤處理是相當重要的考量因素，因為第三方 API 經常變更，並產生非預期的回應值，例如：

• API 的網址或參數可能會在您不知情的情況下進行變更。
• 您的 API 金鑰 (或其他使用者憑證) 可能會過期。
• 回應格式可能會變更，恕不另行通知。

HTTP 狀態碼

由於可能產生非預期的回應，因此建議您檢查 HTTP 狀態碼。根據預設，如果遇到 HTTP 錯誤代碼，UrlFetchApp 會擲回例外狀況。如要變更這項行為，必須傳送選用參數，如以下範例所示：

const options = {
  muteHttpExceptions: true
}
const response = UrlFetchApp.fetch(url, options);
// Any status code greater or equal to 400 is either a client or server error.
if (response.getResponseCode() >= 400) {
  // Error encountered, send an email alert to the developer
  sendFailureEmail();
}

回應結構

當第三方 API 變更時，開發人員通常不會立即發現可能影響指令碼的變更。舉例來說，如果 OpenWeatherMap 範例中傳回的 name 屬性變更為 locationName，使用這個屬性的指令碼就會失敗。

因此，測試傳回的結構是否如預期有利，例如：

const weatherData = JSON.parse(json);
if (weatherData && weatherData.name) {
  console.log('Location is : ' + name);
} else {
  console.log('Data not in expected format');
}

使用 UrlFetchApp 的 POST 資料

OpenWeatherMap 只會擷取已擷取的資料，請見簡介範例。一般來說，不會變更遠端伺服器狀態的 API 呼叫會使用 HTTP GET 方法。

GET 方法是 UrlFetchApp 的預設方法。不過，有些 API 呼叫 (例如呼叫可傳送簡訊的服務) 需要使用其他方法，例如 POST 或 PUT。

為了說明如何搭配 UrlFetchApp 使用 POST 呼叫，以下範例示範瞭如何與協作訊息應用程式 Slack 整合，以便向 Slack 使用者和群組傳送 Slack 訊息。

設定 Slack

本指南假設您已註冊 Slack 帳戶。

與前例中的 OpenWeatherMap 相同，需要取得權杖以啟用傳送訊息。Slack 提供不重複的網址，可讓您傳送訊息給團隊，名為「傳入的 Webhook」。

按一下「Add Incoming WebHooks Integration」(新增連入 WebHook 整合)，然後按照操作說明設定傳入的 Webhook。這個程序應核發用於訊息的網址。

發出 POST 要求

設定連入 Webhook 後，提出 POST 要求即可，只要在傳送至 UrlFetchApp.fetch 的 options 參數中使用一些額外屬性即可：

• method：如前所述，這會預設為 GET，但在此處，我們會覆寫並將其設為 POST。

• payload：這是要做為 POST 要求的一部分傳送至伺服器的資料。在這個範例中，Slack 預期物件已序列化為 JSON 格式，如 Slack 說明文件中所述。為此，系統會使用 JSON.stringify 方法，並將 Content-Type 設為 application/json。

    // Change the URL for the one issued to you from 'Setting up Slack'.
    const SLACK_URL = 'https://hooks.slack.com/services/AAAA/BBBB/CCCCCCCCCC';
    const slackMessage = {
      text: 'Hello, slack!'
    };
  
    const options = {
      method: 'POST',
      contentType: 'application/json',
      payload: JSON.stringify(slackMessage)
    };
    UrlFetchApp.fetch(SLACK_URL, options);
  

擴充 Slack 範例

上方範例顯示啟用傳入訊息至 Slack 的最低數量。延伸範例說明瞭建立和傳送廣告活動成效報表至群組的方式，以及一些格式設定和顯示選項。

如要進一步瞭解 Slack 訊息，請參閱 Slack 說明文件中的訊息格式。

表單資料

上例示範如何使用 JSON 字串做為 POST 要求的 payload 屬性。

視 payload 的格式而定，UrlFetchApp 會採用不同的方法建構 POST 要求：

• 當 payload 是字串時，字串引數會以要求內文的形式傳送。

• 當 payload 是物件時，例如值的對應：

  {to: '[e-mail]', subject:'Test', body:'Hello, World!'}
  

  鍵/值組合會轉換為表單資料：

  subject=Test&to=[e-mail]&body=Hello,+World!
  

  此外，要求的 Content-Type 標頭會設為 application/x-www-form-urlencoded。

有些 API 要求在提交 POST 要求時使用表單資料，因此從 JavaScript 物件自動轉換為表單資料對您很有用。

HTTP 基本驗證

HTTP 基本驗證是最簡單的驗證方式之一，有許多 API 會使用這種驗證方式。

驗證方法是將經過編碼的使用者名稱和密碼附加到每個要求中的 HTTP 標頭。

建立要求

您必須完成下列步驟，才能產生經過驗證的要求：

1. 使用冒號 (例如 username:password) 將使用者名稱和密碼結合，即可形成通關密語。
2. Base64 會將通關密語編碼，例如 username:password 會變成 dXNlcm5hbWU6cGFzc3dvcmQ=。
3. 在要求中附加 Authorization 標頭，格式為 Authorization: Basic <encoded passphrase>

下列程式碼片段說明如何在 Google Ads 指令碼中完成這項操作：

const USERNAME = 'your_username';
const PASSWORD = 'your_password';
const API_URL = 'http://<place_api_url_here>';

const authHeader = 'Basic ' + Utilities.base64Encode(USERNAME + ':' + PASSWORD);
const options = {
  headers: {Authorization: authHeader}
}
// Include 'options' object in every request
const response = UrlFetchApp.fetch(API_URL, options);

Plivo

Plivo 服務可透過其 API 傳送及接收簡訊。這個範例說明如何傳送訊息。

1. 向 Plivo 註冊。
2. 將範例指令碼貼到 Google Ads 中的新指令碼中。
3. 將 PLIVO_ACCOUNT_AUTHID 和 PLIVO_ACCOUNT_AUTHTOKEN 值替換為管理資訊主頁中的值。
4. 在指令碼中插入您的電子郵件地址，以利接收錯誤通知。
5. 如要使用 Plivo，您必須購買號碼，或將號碼新增至試用帳戶。新增可與試用帳戶搭配使用的沙箱號碼。
6. 同時新增寄件者和收件者的號碼。
7. 將指令碼中的 PLIVO_SRC_PHONE_NUMBER 更新為剛註冊的其中一個沙箱號碼。其中應包含國際國家/地區代碼，例如 447777123456 代表英國電話號碼。

Twilio

Twilio 服務可透過其 API 傳送及接收簡訊。這個範例說明如何傳送訊息。

1. 向 Twillio 註冊。
2. 將範例指令碼貼到 Google Ads 中的新指令碼中。
3. 將 TWILIO_ACCOUNT_SID 和 TWILIO_ACCOUNT_AUTHTOKEN 值替換為帳戶主控台頁面上顯示的值。
4. 將 TWILIO_SRC_PHONE_NUMBER 替換為資訊主頁中的數字，這是 Twilio 授權傳送訊息的號碼。

OAuth 1.0

許多熱門服務都使用 OAuth 進行驗證。OAuth 提供多種變種版本和版本。

然而，如果是 HTTP 基本驗證，使用者只有一個使用者名稱和密碼，則 OAuth 可讓第三方應用程式使用第三方應用程式專屬憑證，授予第三方應用程式與資料的存取權。此外，存取權範圍也會與應用程式有所不同。

如需 OAuth 1.0 的背景資訊，請參閱 OAuth 核心指南。具體而言，請參閱 6. 使用 OAuth 進行驗證。在完整的三足式 OAuth 1.0 中，程序如下：

1. 應用程式 (「消費者」) 會取得要求憑證。
2. 使用者授權要求權杖。
3. 應用程式交換要求權杖，以便取得存取權杖。
4. 針對所有後續資源要求，存取權杖會用於已簽署的要求。

如果第三方服務在沒有使用者互動的情況下使用 OAuth 1.0 (例如 Google Ads 指令碼需要)，則無法執行步驟 1、2 和 3。因此，某些服務會從其設定主控台發出存取權杖，允許應用程式直接前往步驟 4。這就是所謂的單足式 OAuth 1.0。

Google Ads 指令碼中的 OAuth 1.0

如果是 Google Ads 指令碼，系統通常會將每個指令碼解讀為一個應用程式。 透過服務的控制台/管理設定頁面，通常必須執行下列操作：

• 設置應用程式設定來代表指令碼。
• 指定要將哪些權限延伸至指令碼。
• 取得用戶端金鑰、用戶端密鑰、存取權杖和存取密鑰，以便與單足 OAuth 搭配使用。

OAuth 2.0

熱門 API 中使用的是 OAuth 2.0，用於提供使用者資料的存取權。特定第三方服務的帳戶擁有者將授權給特定應用程式，允許該應用程式存取使用者資料。優點在於擁有者：

• 不需要與應用程式分享帳戶憑證。
• 可以控管哪些應用程式可以存取個別資料，以及存取資料的範圍。(例如，授予的存取權可能為唯讀，或只有資料子集)。

如要在 Google Ads 指令碼中使用已啟用 OAuth 2.0 的服務，請按照下列步驟操作：

指令碼外

授權 Google Ads 指令碼透過第三方 API 存取您的使用者資料。在大多數情況下，這涉及在第三方服務的控制台中設定應用程式。這個應用程式代表您的 Google Ads 指令碼。

您可以指定 Google Ads 指令碼 應用程式應授予的存取權，而系統會通常會指派用戶端 ID。這可讓您透過 OAuth 2 控制哪些應用程式可存取第三方服務的資料，以及他們可以查看或修改資料的哪些部分。

在指令碼中

透過遠端伺服器授權。視伺服器允許的授權類型而定，您必須遵循一組不同的步驟 (稱為「流程」)，但最終都會產生存取權杖，用於該工作階段的所有後續要求。

提出 API 要求。透過每項要求傳遞存取權杖。

授權流程

每種授權類型和相應的流程可滿足不同的使用情境。舉例來說，當使用者參與互動工作階段時，系統會採用不同的流程，而當情況需要應用程式在使用者沒有表現的情況下在背景執行。

API 供應商會決定他們接受的授權類型，這些資訊可引導使用者繼續整合 API。

導入作業

針對各種不同的 OAuth 流程，目標是取得存取權杖，然後系統接著會將該權杖用於工作階段的其餘部分來驗證要求。

範例程式庫說明如何為每個不同流程類型進行驗證。上述每個方法都會傳回一個物件，以取得並儲存存取權杖，並協助驗證要求。

一般使用模式如下：

// Authenticate using chosen flow type
const urlFetchObj = OAuth2.<flow method>(args);
// Make request(s) using obtained object.
const response1 = urlFetchObj.fetch(url1);
const response2 = urlFetchObj.fetch(url2, options);

注意： 由於 Google Ads 指令碼短期內運作過短，請勿嘗試在此範例程式庫中重新整理取得的存取權杖。

用戶端憑證授予

用戶端憑證授權是較簡單的 OAuth2 流程之一，應用程式可交換專屬於應用程式的 ID 和密鑰，以用於核發限時的存取權杖。

// Access token is obtained and cached.
const authUrlFetch = OAuth2.withClientCredentials(
    tokenUrl, clientId, clientSecret, optionalScope));
// Use access token in each request
const response = authUrlFetch.fetch(url);
// ... use response

重新整理權杖授權

更新憑證授權與用戶端憑證授予類似，就像對伺服器發出的簡單要求會傳回可在工作階段中使用的存取權杖。

取得更新權杖

更新權杖授予的差別在於，用戶端憑證授予所需的詳細資料來自應用程式設定 (例如在服務的控制台中)，系統會在較複雜的流程 (例如授權代碼授權) 中授予更新憑證，因此需要使用者進行互動：

使用 OAuth Playground 取得更新權杖

OAuth2 Playground 提供 UI 可讓使用者逐步透過授權碼授權的方式取得更新權杖。

右上角的設定按鈕可讓您定義要在 OAuth 流程中使用的所有參數，包括：

• 授權端點：用於做為授權流程的起點。
• 權杖端點：與更新權杖搭配使用，以取得存取權杖。
• client ID and Secret：應用程式的憑證。

使用指令碼取得更新權杖

如需以指令碼為基礎的替代方法，請參閱重新整理權杖產生範例。

重新整理權杖使用情形

執行初始授權後，服務即可發出更新權杖，這個權杖會類似於用戶端憑證流程。以下提供兩個範例：

const authUrlFetch = OAuth2.withRefreshToken(tokenUrl, clientId, clientSecret,
    refreshToken, optionalScope);
const response = authUrlFetch.fetch(url);
// ... use response

Search Ads 360 範例

Search Ads 360 是可與更新權杖搭配使用的 API 範例。 在這個範例中，指令碼會產生並傳回報表。如要進一步瞭解可執行的其他動作，請參閱 Search Ads 360 API 參考資料。

建立指令碼

1. 在 API 控制台中建立新專案，並按照 DoubleClick 指南中的步驟啟用 DoubleClick Search API，並取得用戶端 ID、用戶端密鑰和更新權杖。
2. 將範例指令碼貼到 Google Ads 中的新指令碼中。
3. 將範例 OAuth2 程式庫貼到程式碼清單下方。
4. 修改指令碼，使其包含用戶端 ID、用戶端密鑰和更新權杖的正確值。

Apps Script Execution API 範例

這個範例說明如何使用 Apps Script Execution API 在 Apps Script 中執行函式。如此一來，系統就能從 Google Ads 指令碼呼叫 Apps Script。

建立 Apps Script 指令碼

建立新指令碼。以下範例將列出雲端硬碟中的 10 個檔案：

function listFiles() {
  const limit = 10;
  const files = [];
  const fileIterator = DriveApp.getFiles();
  while (fileIterator.hasNext() && limit) {
    files.push(fileIterator.next().getName());
    limit--;
  }
  return files;
}

設定要執行的 Apps Script

1. 儲存指令碼。
2. 按一下「資源」>「Cloud Platform 專案」。
3. 按一下專案名稱，前往 API 控制台。
4. 接著前往「API 和服務」，
5. 啟用適當的 API (在此情況下為 Drive API 和 Apps Script Execution API)。
6. 透過選單中的「Credentials」項目建立 OAuth 憑證。
7. 返回指令碼，依序前往「Publish」(發布) >「Deploy as API Executable」，發布要執行的指令碼。

建立 Google Ads 指令碼

1. 將範例指令碼貼到 Google Ads 中的新指令碼中。
2. 此外，將範例 OAuth2 程式庫貼到程式碼清單下方。
3. 修改指令碼，使其包含用戶端 ID、用戶端密鑰和更新權杖的正確值。

服務帳戶

除了上述授權類型之外，另一個選擇是「服務帳戶」的概念。

與上述服務帳戶不同，服務帳戶不會用於存取使用者資料：在驗證之後，要求是由服務帳戶代表應用程式提出，而非擁有該專案的使用者。舉例來說，如果服務帳戶是用來使用 Drive API 建立檔案，那麼這會屬於服務帳戶，根據預設，專案擁有者無法存取。

Google Natural Language API 範例

自然語言 API 提供文字的情緒分析和實體分析功能。

這個範例說明如何計算廣告文字 (包括廣告標題或說明) 的情緒。這樣就能評估訊息的正面程度與訊息的規模：如果是，「我們賣蛋糕」或「我們最好在倫敦銷售最好吃的蛋糕」立即購買！？

設定指令碼

1. 在 API 控制台建立新專案
2. 啟用 Natural Language API
3. 啟用專案的計費功能。
4. 建立服務帳戶。下載憑證 JSON 檔案。
5. 將範例指令碼貼到 Google Ads 中的新指令碼中。
6. 此外，將範例 OAuth2 程式庫貼到程式碼清單下方。
7. 替換必要的值：
   • serviceAccount：例如 [e-mail] 的服務帳戶電子郵件地址。
   • key：建立服務帳戶時下載的 JSON 檔案金鑰。開始日期：-----BEGIN PRIVATE KEY...，結束日期：...END PRIVATE KEY-----\n。

API 回應

API 能以多種格式傳回資料。其中最值得注意的是 XML 和 JSON

JSON

JSON 通常比 XML 更簡單，無法做為回應格式。不過，仍有一些問題可能發生。

回應驗證

從呼叫 API 取得成功回應後，一般的下一步是使用 JSON.parse 將 JSON 字串轉換為 JavaScript 物件。此時，系統可以處理剖析「失敗」的情況：

const json = response.getContentText();
try {
  const data = JSON.parse(json);
  return data;
} catch(e) {
  // Parsing of JSON failed - handle error.
}

此外，如果 API 不在您的控管範圍內，請考慮回應結構可能會變更，且屬性也可能不存在：

// Less good approach
// Assumes JSON was in form {"queryResponse": ...} when parsed.
const answer = data.queryResponse;

// Better approach
if (data && data.queryResponse) {
  const answer = data.queryResponse;
} else {
  // Format of API response has changed - alert developer or handle accordingly
}

XML

驗證

XML 仍然是建構 API 的熱門格式。您可以使用 XmlService parse 方法剖析 API 呼叫的回應：

const responseText = response.getContentText();
try {
  const document = XmlService.parse(responseText);
} catch(e) {
  // Error in XML representation - handle accordingly.
}

雖然 XmlService.parse 會偵測 XML 中的錯誤並視情況擲回例外狀況，但也無法根據結構定義驗證 XML。

根元素

成功剖析 XML 文件後，即可使用 getRootElement() 方法取得根元素：

const document = XmlService.parse(responseText);
const rootElement = document.getRootElement();

命名空間

在以下範例中，系統會使用 Sportradar API 取得所選相符項目的足球結果。XML 回應採用以下格式：

<schedule xmlns="http://feed.elasticstats.com/schema/soccer/sr/v2/matches-schedule.xsd">
  <matches>
     ...
  </matches>
</schedule>

請注意在根元素中指定命名空間的方式。因此，您必須：

• 從文件中擷取命名空間屬性。
• 在掃遍及存取子項元素時，請使用這個命名空間。

以下範例說明如何存取上述文件程式碼片段中的 <matches> 元素：

const document = XmlService.parse(xmlText);
const scheduleElement = document.getRootElement();
// The namespace is required for accessing child elements in the schema.
const namespace = scheduleElement.getNamespace();
const matchesElement = scheduleElement.getChild('matches', namespace);

取得值

以足球賽程為例：

<match status="..." category="..." ... >
  ...
</match>

可擷取屬性，例如：

const status = matchElement.getAttribute('status').getValue();

您可以使用 getText() 讀取元素中包含的文字，但這些文字會串連在元素有多個文字子項的情況下串連。如果可能有多個文字子項，請考慮使用 getChildren() 並逐一檢查每個子項。

Sportradar 範例

這個完整的運動錶帶範例說明瞭足球比賽的詳細擷取資訊，尤其是英格蘭超級聯賽的比賽。Soccer API 是 Sportradar 提供的眾多運動動態消息之一。

設定 Sportradar 帳戶

1. 前往 Sportradar 開發人員網站
2. 註冊試用帳戶。
3. 註冊完成，請登入帳戶。
4. 登入後，前往 MyAccount。

Sportradar 將不同的運動分為不同的 API。舉例來說，您可以購買 Soccer API 的存取權，而非 Tennis API。您建立的每個應用程式可以有不同的運動項目，以及不同的鍵。

1. 按一下「Application」下方的「Create a new Application」。為應用程式命名和說明，並忽略網站欄位。
2. 僅選取「為歐洲試用版 (第 2 版) 核發新金鑰」。
3. 按一下「註冊應用程式」。

成功後，這個頁面應該會顯示內含新 API 金鑰的頁面。

1. 將範例指令碼貼到 Google Ads 中的新指令碼中。
2. 將清單中的 API 金鑰替換為上述取得的金鑰，然後編輯電子郵件地址欄位。

疑難排解

使用第三方 API 時，可能有許多原因導致錯誤，例如：

• 用戶端以 API 不預期的格式發出要求至伺服器。
• 用戶端預期的回應格式與遇到的格式不同。
• 用戶端使用無效權杖或金鑰，或是保留為預留位置的值。
• 用戶端達到用量限制。
• 用戶端提供的參數無效。

在這些情況下，有時需要找出問題原因的第一步，就是檢查造成錯誤的回應詳細資訊。

剖析回應

根據預設，所有傳回錯誤的回應 (400 以上的狀態碼)，都會由 Google Ads 指令碼引擎擲回。

如要避免這個行為並允許檢查錯誤和錯誤訊息，請將選用參數的 muteHttpExceptions 屬性設為 UrlFetchApp.fetch。例如：

const params = {
  muteHttpExceptions: true
};
const response = UrlFetchApp.fetch(url, params);
if (response.getResponseCode() >= 400) {
  // ... inspect error details...
}

常見狀態碼

• 200 OK 表示成功。如果回應不含預期資料，請考慮：

  • 部分 API 支援指定要使用的欄位和/或回應格式。詳情請參閱 API 說明文件。
  • 一個 API 可能有多項可供呼叫的資源。請參閱說明文件，以判斷其他資源是否更適合使用，並傳回您所需的資料。
  • API 可能在編寫程式碼後有所變更。如需進一步說明，請參閱說明文件或開發人員。

• 400 Bad Request 通常表示傳送至伺服器的要求格式或結構不正確。請檢查要求，並與 API 規格比較，確保符合預期。如要進一步瞭解如何檢查要求，請參閱「檢查要求」。

• 401 Unauthorized 通常表示系統正在呼叫 API，但未提供或成功執行授權。

  • 如果 API 使用基本授權，請確認已在要求中建構並提供 Authorization 標頭。
  • 若 API 使用 OAuth 2.0，請確認系統已取得存取權杖，並提供以不記名權杖形式提供。
  • 至於其他有關授權的其他變化版本，請務必提供要求所需的憑證。

• 403 Forbidden 表示使用者沒有要求資源的權限。

  • 確認已向使用者授予必要權限，例如在檔案型要求中，向使用者授予檔案存取權。

• 404 Not Found 表示要求的資源不存在。

  • 檢查 API 端點使用的網址是否正確。
  • 如要擷取資源，請檢查所參照的資源是否存在 (例如檔案是否存在檔案型 API)。

檢查要求

當 API 回應指出要求的格式錯誤 (例如 400 狀態碼) 時，檢查要求非常實用。為協助檢查要求，UrlFetchApp 提供 fetch() 方法的隨附方法，稱為 getRequest()

這個方法不會傳送要求至伺服器，而是建構要求並傳回「可能」經過傳送的要求。這可讓使用者檢查要求的元素，確保要求看起來正確無誤。

例如，如果要求中的表單資料包含許多串連的字串，則錯誤可能位於您為了產生該表單資料而建立的函式中。簡單來說：

const request = UrlFetchApp.getRequest(url, params);
console.log(request);
// Now make the fetch:
const response = UrlFetchApp.fetch(url, params);
// ...

可讓您檢查要求的元素

記錄要求與回應

為協助檢查第三方 API 的要求和回應整個程序，您可以使用下列輔助函式取代 UrlFetchApp.fetch()，以便記錄要求和回應。

1. 將程式碼中所有的 UrlFetchApp.fetch() 例項替換為 logUrlFetch()。

2. 將下列函式新增至指令碼的結尾。

   function logUrlFetch(url, opt_params) {
     const params = opt_params || {};
     params.muteHttpExceptions = true;
     const request = UrlFetchApp.getRequest(url, params);
     console.log('Request:       >>> ' + JSON.stringify(request));
     const response = UrlFetchApp.fetch(url, params);
     console.log('Response Code: <<< ' + response.getResponseCode());
     console.log('Response text: <<< ' + response.getContentText());
     if (response.getResponseCode() >= 400) {
       throw Error('Error in response: ' + response);
     }
     return response;
   }
   

執行指令碼時，所有要求和回應的詳細資料都會記錄到主控台，方便您偵錯。