錯誤代碼

以下是REST API錯誤碼清單，並說明如何將錯誤傳回至應用程式。

處理與記錄例外

針對Marketo進行開發時，發生非預期的例外狀況時，請務必記錄請求和回應。 雖然重新驗證可以安全地處理某些型別的例外（例如過期的驗證），但其他例外可能需要支援互動，而在此情況下將一律要求請求和回應。

錯誤型別

Marketo REST API在正常操作下可傳回三種不同型別的錯誤：

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

HTTP層級錯誤

在正常作業情況下，Marketo應該只會傳回兩個HTTP狀態程式碼錯誤， 413 Request Entity Too Large、和 414 Request URI Too Long. 擷取錯誤、修改請求和重試都可以復原這些設定，但使用智慧編碼實務作法，您絕不應該在萬不得已的情況下遇到這些設定。

如果要求裝載超過1MB，Marketo會傳回413，若是Import Lead，會傳回10MB。 在大多數情況下，應該不會達到這些限制，但新增檢查至要求的大小，並移動任何記錄（這會導致限制超過新的要求）應該可以防止任何情況（這會導致任何端點傳回此錯誤）。

當GET要求的URI超過8KB時，將會傳回414。 若要避免出現這種情況，請檢查查詢字串的長度，看看是否超過此限制。 如果它確實將您的請求變更為POST方法，則使用其他引數將您的查詢字串輸入為請求內文 _method=GET. 這放棄了URI的限制。 在大多數情況下很少達到此限制，但在擷取具有長的個別篩選值（例如GUID）的大量記錄時，這比較常見。
此 身分 端點可能會傳回401 Unauthorized錯誤。 這通常是因為無效的使用者端ID或無效的使用者端密碼。 HTTP層級錯誤代碼

回應層級錯誤

回應層級錯誤出現於 success 回應的引數設為false，其結構如下：

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

「錯誤」陣列中的每個物件都有兩個成員， code，引號為601到799的整數，以及 message 提供錯誤的純文字原因。 6xx程式碼一律會指出要求完全失敗且未執行。 601「存取權杖無效」即是範例，您可使用要求重新驗證並傳遞新的存取權杖來復原它。 7xx錯誤表示請求失敗，可能是因為未傳回任何資料，或是請求引數化不正確，例如包含無效的日期，或遺漏必要的引數。

回應層級錯誤代碼

傳回此回應程式碼的API呼叫不會算入您的每日配額或速率限制中。

記錄層級 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，而訊息會指出略過記錄的原因。 例如，Sync Leads請求的「action」設為「createOnly」，但已提交記錄中的索引鍵之一已有潛在客戶。 此案例會傳回代碼1005，而如上所示，訊息為「潛在客戶已存在」。

記錄層級錯誤代碼