錯誤代碼

Marketo REST API會在HTTP、回應或記錄層級傳回錯誤。 此頁面說明每種錯誤型別，並列出相關的錯誤代碼。

處理與記錄例外

當整合發生非預期的例外狀況時，記錄請求和回應。 有些例外狀況（例如過期的驗證）可透過重新驗證來處理。 其他例外情況可能需要支援部門的協助，以要求相關的請求和回應詳細資料。

錯誤型別

Marketo REST API在正常作業期間可能會傳回三種型別的錯誤：

回應層級和記錄層級錯誤傳回HTTP狀態代碼200。 對於所有錯誤型別，請勿評估HTTP原因片語，因為它是選用的，而且可能會有所變更。

HTTP層級錯誤

在正常作業期間，Marketo傳回兩個HTTP狀態代碼錯誤： 413 Request Entity Too Large和414 Request URI Too Long。 若要從任一錯誤中復原，請修改請求並重試。 您可以在提交前先檢查要求大小，以避免發生這些錯誤。

當請求承載超過1MB時，Marketo會傳回413，或匯入潛在客戶會傳回10MB。 在提交之前檢查請求大小。 如果記錄導致請求超過限制，請將這些記錄移至另一個請求。

當GET要求的URI超過8KB時，Marketo會傳回414。 提交前請檢查查詢字串長度。 如果超過限制，請將要求方法變更為POST，將查詢字串放入要求內文中，然後新增_method=GET引數。 長URI在擷取具有長篩選值（例如GUID）的大型記錄批次時最常見。

身分端點可能會傳回401 Unauthorized錯誤，通常是因為使用者端識別碼或使用者端密碼無效。 下表列出HTTP層級的錯誤碼。

回應層級錯誤

當回應將success引數設為false時，就會發生回應層級錯誤。 它們使用下列結構：

{
    "requestId": "e42b#14272d07d78",
    "success": false,
    "errors": [
        {
            "code": "601",
            "message": "Unauthorized"
        }
    ]
}

「錯誤」陣列中的每個物件包含兩個成員：

6xx程式碼表示整個要求失敗且未執行。 例如，透過重新驗證並使用請求傳遞新存取權杖來從601「存取權杖無效」錯誤中復原。

7xx程式碼表示要求失敗，因為未傳回任何資料或要求引數無效。 原因包括無效的日期或缺少必要引數。

回應層級錯誤代碼

記錄層級 record_level_errors

記錄層級錯誤表示要求有效，但無法完成個別記錄的作業。 含有記錄層級錯誤的回應會遵循以下模式：

回應

{
   "requestId":"e42b#14272d07d78",
   "success":true,
   "result":[
      {
         "id":50,
         "status":"created"
      },
      {
         "id":51,
         "status":"created"
      },
      {
         "status":"skipped",
         "reasons":[
            {
               "code":"1005",
               "message":"Lead already exists"
            }
         ]
      }
   ]
}

結果陣列中的記錄與請求輸入陣列中的記錄顯示順序相同。 每個記錄都可以獨立成功或失敗，如其狀態列位所示。

對於失敗的記錄，「狀態」欄位為「已略過」，記錄包括「原因」陣列。 每個原因都包含「代碼」成員和「訊息」成員。 程式碼一律為1xxx，而訊息則說明略過記錄的原因。

例如，如果「同步銷售機會」請求將「action」設為「createOnly」，而且其中一個已提交的索引鍵已有銷售機會存在，則回應會傳回代碼1005，並出現訊息「Lead already exists」，如上所示。

記錄層級錯誤代碼