API 呼叫結構

本指南說明所有 API 呼叫的通用結構。

若透過用戶端程式庫與 API 互動，您不會 不需要擔心基礎要求詳細資料不過 在測試和偵錯時，瞭解一些相關資訊，就能派上用場。

Google Ads API 為 gRPC API， REST 繫結也就是說，呼叫 API 的方式有兩種。

  1. [建議使用] 建立要求主體， 通訊協定緩衝區，並透過 HTTP/2，將回應反序列化為通訊協定 緩衝區並解讀結果，大部分說明文件都指出 gRPC。

  2. [選用] 建立要求主體做為 JSON 物件，以便使用 HTTP 1.1 傳送至伺服器， 將回應還原為 JSON 物件，然後解讀結果。詳情請參閱 REST 介面指南，進一步瞭解如何使用 REST，

，瞭解如何調查及移除這項存取權。

資源名稱

API 中的大多數物件，都是透過資源名稱字串來識別。這些 使用 REST 介面時，字串也會當成網址使用。查看 REST 介面的資源名稱 成本中心的架構

複合 ID

如果物件 ID 並非全域唯一，則為該物件的複合 ID 會在前面加上父項 ID 和波浪號 (~) 來建構。

舉例來說，由於廣告群組的廣告 ID 並非全域唯一，因此在前面加上 父項物件 (廣告群組) ID 來建立不重複的複合 ID：

  • 第 AdGroupId 個 (共 123 個) + ~ 個 (共 45678 個) = 多媒體廣告AdGroupAdId 123~45678 的廣告群組廣告 ID。

要求標頭

這些是 HTTP 標頭 (或稱 grpc) 隨附的中繼資料) 要求中的主體：

授權

您必須加入 OAuth2 存取權杖，格式為 Authorization: Bearer YOUR_ACCESS_TOKEN，用於識別 直接代表客戶或廣告客戶行事的管理員帳戶 自行管理帳戶。擷取存取權杖的操作說明 請參閱 OAuth2 指南。一個 取得存取權杖後，其效期為一小時。時間 過期，請重新整理存取權杖以擷取新的存取權杖。請注意， 用戶端程式庫會自動重新整理過期的權杖

developer-token

開發人員權杖是一組由 22 個字元組成的字串，可明確識別 Google Ads API 開發人員。範例開發人員權杖字串是 ABcdeFGH93KL-NOPQ_STUv。開發人員權杖應包含 developer-token : ABcdeFGH93KL-NOPQ_STUv 形式。

login-customer-id

這是授權客戶在要求中使用的 ID。 不含連字號 (-)。如果您透過 管理員帳戶，這個標題為必要項目，且必須設為 管理員帳戶

https://googleads.googleapis.com/v17/customers/1234567890/campaignBudgets:mutate

設定 login-customer-id 等同於選擇 登入或點選頂端的個人資料圖片後，Google Ads 使用者介面 沒錯如果您沒有包含此標頭，則會預設為運算子 客戶。

linked-customer-id

只有在第三方應用程式分析供應商服務的情況下，才能使用這個標題 將轉換資料上傳至已連結的 Google Ads 帳戶。

假設帳戶 A 的使用者提供讀取和編輯權限 相關實體，B透過 ThirdPartyAppAnalyticsLink。 連結完成後，帳戶 B 的使用者可以對 A 這個帳戶進行 API 呼叫。 所需的權限在這個例子中 帳戶 A 的權限取決於與帳戶 B 相關的第三方連結。 而非其他 API 呼叫使用的管理員帳戶關係。

第三方應用程式分析供應商發出 API 呼叫的方式如下：

  • linked-customer-id：上傳的第三方應用程式數據分析帳戶 資料 (帳戶：B)。
  • customer-id：要上傳資料的 Google Ads 帳戶 (帳戶) A)。
  • login-customer-id 和 Authorization 標頭：結合 找出可存取 B 帳戶的使用者。

回應標頭

下列標題 (或 gRPC 結尾中繼資料) 都會與回應主體一併傳回建議您記錄這些資訊 以便偵錯

要求 ID

request-id 是用來識別這項要求的專屬字串。

上一頁
資源中繼資料