エラーコード
REST API エラーコードのリストと、エラーがアプリケーションに返される方法を以下で説明します。
例外の処理とログ
Marketo 向けに開発を行う場合、予期しない例外が発生した際にリクエストと応答がログに記録されることが重要です。期限切れの認証などの特定のタイプの例外は、再認証によって安全に処理できますが、他の例外ではサポートのインタラクションが必要になる場合があり、このシナリオでは常にリクエストと応答がリクエストされます。
エラータイプ
Marketo REST API は、通常の操作では次の 3 つの異なるタイプのエラーを返します。
- HTTP レベル:これらのエラーは、
4xx
コードで示されます。 - 応答レベル:これらのエラーは、JSON 応答の "errors" 配列に含まれます。
- レコードレベル:これらのエラーは、JSON 応答の "result" 配列に含まれ、"status" フィールドと "reasons" 配列を使用して個々のレコードごとに示されます。
応答レベルおよびレコードレベルのエラータイプの場合、HTTP ステータスコード 200 が返されます。すべてのエラータイプについて、HTTP 理由フレーズはオプションであり、変更される可能性があるので、評価しないでください。
HTTP レベルのエラー
通常の操作状況では、Marketo は、413 Request Entity Too Large
と 414 Request URI Too Long
の 2 つの HTTP ステータスコードエラーのみを返します。これらは両方とも、エラーをキャッチし、リクエストを変更して再試行することで復元できますが、スマートコードプラクティスを使用すれば、実際にこのような問題が発生することはありません。
リクエストペイロードが 1 MB を超える場合や、「リード読み込み」のケースで 10 MB を超える場合、Marketo は 413 を返します。ほとんどのシナリオでは、これらの制限に達する可能性はほとんどありませんが、リクエストのサイズを確認するチェックを追加し、制限を超える原因となるレコードを新しいリクエストに移動することで、エンドポイントからこのエラーが返される状況を防ぐことができます。
GET リクエストの URI が 8 KB を超えると 414 が返されます。これを回避するには、クエリ文字列の長さがこの制限を超えていないかどうかを確認します。リクエストが POST メソッドに変更される場合は、追加のパラメーター _method=GET
を指定して、クエリ文字列をリクエスト本文として入力します。これにより、URI の制限がなくなります。ほとんどの場合、この制限に達することはまれですが、GUID などの長い個別のフィルター値を持つ大量のレコードを取得する場合は、比較的よくで発生します。
ID エンドポイントは、401 Unauthorized エラーを返す場合があります。これは通常、クライアント ID やクライアント秘密鍵が無効であることが原因です。HTTP レベルのエラーコード
応答レベルのエラー
応答レベルのエラーは、応答の success
パラメーターが false に設定されている場合に発生し、次のように構造化されます。
{
"requestId": "e42b#14272d07d78",
"success": false,
"errors": [
{
"code": "601",
"message": "Unauthorized"
}
]
}
"errors" 配列の各オブジェクトには、601 から 799 までの引用符で囲まれた整数である code
と、エラーの理由をプレーンテキストで示す message
の 2 つのメンバーがあります。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"
}
]
}
]
}
呼び出しの結果配列に含まれるレコードは、リクエストの入力配列と同じ方法で順序付けられます。
成功したリクエストの各レコードは、個別に成功または失敗する可能性があります。この結果は、応答の結果配列に含まれる各レコードのステータスフィールドで示されます。これらのレコードの "status" フィールドは "skipped" になり、"reasons" 配列が存在します。各理由には、"code" メンバーと "message" メンバーが含まれます。コードは常に 1xxx で、メッセージにはレコードがスキップされた理由が示されます。例えば、「リードを同期」リクエストの"action" が "createOnly" に設定されているが、送信済みレコードのキーの 1 つに対してリードが既に存在する場合です。この場合、コード 1005 が返され、上記のように「リードは既に存在します」というメッセージが表示されます。