> ## Documentation Index
> Fetch the complete documentation index at: https://help.dingtalk.io/llms.txt
> Use this file to discover all available pages before exploring further.

# webhook で自動化をトリガーする

> Webhook は異なるシステム間でデータや情報を相互にやり取りできる仕組みです。関心のあるシステムで新しいイベントが発生すると、自動的にデータを受け取れます。Webhook アドレスは通信用のアドレスのようなもので、データを受信し情報をタイムリーに取得します。

## 1 機能概要

Webhook は異なるシステム間でデータや情報を相互にやり取りできる仕組みです。**関心のあるシステムで新しいイベントが発生すると、自動的にデータを受け取れます**。Webhook アドレスは通信用のアドレスのようなもので、データを受信し情報をタイムリーに取得できます。

* 注意：Webhook は開発者向けの高度な機能です。開発者の支援を受けて利用してください。

> ⚠️webhook アドレスは厳重に管理してください。外部サイトに公開しないでください。漏洩した場合、大量の有害情報が流入し、組織の開発リソースを消費して、リソース損失や安全リスクを招く恐れがあります。

## 2 利用シーン

Webhook を設定すると、特定のシステムやアプリの更新を「サブスクライブ」できます。例えば：

* 内部システム間のデータ同期：ERP や CRM などの内部システムに Webhook を設定すると、システム間でデータを同期でき、手動での同期作業が不要になります。
* ウェブサイトのコンテンツ更新通知：関心のあるウェブサイトに Webhook を設定すると、新しいコンテンツがあると自動的に通知され、何度もサイトを開いて確認する必要がなくなります。
* 監視・アラート通知：監視システムやアラートプラットフォームに Webhook を設定すると、システムの状態をリアルタイムで監視でき、問題を素早く処理できます。

## 3 利用方法

### 3.1 トリガーキーワードを設定する

受信したデータにキーワードが含まれている場合のみ、ワークフローがトリガーされます。「キーワード追加」をクリックすると複数のキーワード（上限 10 個）を設定でき、受信データにいずれかのキーワードが含まれていればワークフローがトリガーされます。

### 3.2 パラメータ形式を設定する

関心のあるシステムからパラメータを受信すると、それらのパラメータは後続のステップにも引き継がれます。そのため、**パラメータ形式は後続ステップでパラメータをどう解析・参照するかを決定します。**

#### 3.2.1 パラメータ形式に JSON を選択した場合

後続ステップでは JSON のルールに従ってパラメータが構造化解析されます。そのため、**パラメータのサンプルを手動で入力する必要があります。これにより後続ステップで構造化されたデータを参照できます。**

#### 3.2.2 パラメータ形式に Text を選択した場合

後続ステップでは、これらのパラメータを text 形式でひとまとめに参照できます。（特に、パラメータが [DingTalk ロボットがサポートするメッセージ構造](https://open.dingtalk.com/document/orgapp/custom-bot-send-message-type#66407430cd5xr "DingTalk ロボットがサポートするメッセージ構造")に準拠していれば、「該当グループへメッセージ送信」のアクションで「メッセージソース」を「ソースデータ解析」に切り替えると、これらのパラメータを自動的にメッセージ本文として送信できます。）

#### 3.2.3 パラメータ形式に None を選択した場合

後続ステップではこれらのパラメータを参照できません。

Webhook パラメータの詳細説明

### 3.3 webhook アドレスを設定する

「コピー」ボタンをクリックし、webhook アドレスを連携対象のシステムに設定します。（自動化ワークフローごとに専用の webhook アドレスが自動生成されます。**webhook アドレスは厳重に管理してください。漏洩した場合、大量の有害情報が流入し、組織の開発リソースを消費する恐れがあります。**）

### 3.4 Http リクエストを送信する

リクエストを送信すると、自動化ワークフローがトリガーされます。

| パラメータ  | 値                        | 例                                                                                                                                                       |
| ------ | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Method | POST                     | -                                                                                                                                                       |
| URL    | トリガー条件内の Webhook アドレス    | [https://connector.dingtalk.io/webhook/flow/xxxxx](https://connector.dingtalk.io/webhook/flow/xxxxx "https://connector.dingtalk.io/webhook/flow/xxxxx") |
| Body   | JSON。トリガーキーワードを含む必要があります | \{  "key": "value"  }                                                                                                                                   |

## 4 リクエストヘッダー（Header）と例

| **名前**​       | **タイプ**​ | **必須**​ | **説明**​                                                                                                                                                                                                                                                                                                                                       |
| ------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authorization | string   | 否       | 認証チェック（Bearer token）はリクエストヘッダー（Header）経由で AI テーブル自動化に渡します。Header の形式（大文字小文字を区別）は以下のとおりです：  --header 'Authorization: Bearer \\\[実際の Bearer token]'  シングルクォートは実際の Header に必ず入力します。角括弧 \\\[] は変数を示すだけで、実際の Header には入力不要です。  ここでの Header の Key（キー）は固定で Authorization、Value（値）は固定の接頭辞 Bearer が付きます。  Bearer 接頭辞と実際の Bearer token の間には半角スペースが必要です。 |
| Client-Token  | string   | 否       | 冪等性の Header では Key（キー）は固定で Client-Token、Value（値）はユーザーが生成し、通常は uuid を使います。  値が空の場合、新規リクエストとして発信されます。値が空でない場合、冪等な更新操作となり、同じ値であれば 3 時間以内に 1 回しかトリガーされません。                                                                                                                                                                                        |

Bearer token のサンプルコードは以下のとおりです（角括弧は置き換える変数で、実際のコードには記述不要）：

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl --location --request POST '[実際の webhook アドレス]' \
--header 'Authorization: Bearer [実際の Bearer token]' \
--header 'Content-Type: application/json' \
--data-raw '{[実際のリクエスト本文の内容]}'
```

## 5 リクエストボディ

必要に応じて設定してください。形式は JSON 仕様に準拠する必要があります。

## 6 レスポンスボディと例

レスポンスボディの code が 0 でない場合は失敗を示します。

code が 0 でない場合、下表の「関連エラー」のエラーコードと文言を参照して問題を切り分けできます。

webhook の受信が正常な場合、レスポンスボディの例は以下のとおりです：

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"msg": "",
"data": { },
"code": 0
}
```

webhook でエラーが発生した場合、レスポンスボディの例は以下のとおりです：

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"data": { },
"code": 800004509,
"msg": "webhook trigger workflow is disabled"
}
```

## 7 エラーコード

webhook トリガーでエラーが発生した場合、リクエスト送信側でエラーを確認し、下表のエラーコードと文言を参照して切り分けてください。

| **エラーコード**​ | **エラーメッセージ**​                                                | **エラー原因**​                                                                                                                                                                                                   | **解決方法**​                                              |
| ----------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------ |
| 800005649   | 認証チェックを通過していません                                              | 認証チェックが有効ですが、HTTP リクエストに含まれる認証情報が自動化ワークフローで必要な認証情報と一致しないため、ワークフローが実行できません。                                                                                                                                   | 認証情報を再確認・再入力してください。                                    |
| 800005650   | IP アドレスがホワイトリストにありません。確認してください                               | IP ホワイトリストが有効で、リクエスト送信元の IP がホワイトリストに含まれていません。                                                                                                                                                               | 該当 IP をホワイトリストに追加するか、IP アドレスを変更して再送信してください。            |
| 800005647   | リクエスト内容のサイズが上限を超えています。内容を減らしてください                            | webhook が受信する HTTP リクエストのサイズが 4 MB を超えました。                                                                                                                                                                   | 内容を減らしてください。                                           |
| 800005646   | 自身を呼び出す HTTP ノードが存在し、無限ループになります。HTTP ノードのリクエスト URL を変更してください | 自動化ワークフローのトリガー条件が「webhook トリガー時」、アクションが「HTTP リクエスト送信」で、HTTP のリクエスト URL が当該ワークフローの webhook アドレスと一致しているため、ワークフローがループトリガーに陥っています。                                                                               | 「HTTP リクエスト送信」内の URL を変更し、webhook アドレスと一致しないようにしてください。 |
| 800005652   | リクエストが頻繁すぎます。後ほどお試しください                                      | webhook が受信する HTTP リクエストの頻度が制限を超え、レート制限がかかっています。  -   AI テーブル全体の webhook トリガー頻度上限は 50 回/秒です。  -   1 つの自動化ワークフローの webhook トリガー頻度上限は 5 回/秒です。  -   認証チェック（Bearer token）が無効な自動化ワークフローでは、ワークフローごとの頻度上限は 1 回/秒です。 | 後ほど再試行してください。                                          |
| 800006003   | リクエストボディが JSON 形式に準拠していません。修正後に再リクエストしてください                  | 通常は「リクエスト送信で出力を設定」の方法で出力を設定する際に、受信したリクエストボディの JSON 形式に誤りがある場合に発生します。                                                                                                                                         | リクエストボディの JSON を再確認・修正してから再試行してください。                   |

## 8 活用事例

1、もしあなたが飲食企業の管理者で、**社内の商品管理システムのデータを DingTalk のグループチャットへ即時同期したい**場合、「パラメータサンプル」に**商品管理システムから渡されるパラメータサンプル**（新商品の名称、規格、ベース、原料など）を手動で入力し、「該当グループへメッセージ送信」でメッセージ内容をカスタマイズします。+ ボタンをクリックして**これらのパラメータを参照すれば、新商品の詳細情報をグループへタイムリーに同期できます。**

2、**以前グループチャットで「カスタムロボット」を使ったことがあり**、関心のあるシステムから渡されるパラメータが [DingTalk ロボットがサポートするメッセージ構造](https://open.dingtalk.com/document/orgapp/custom-bot-send-message-type#66407430cd5xr "DingTalk ロボットがサポートするメッセージ構造")に準拠している場合、「該当グループへメッセージ送信」のアクションで<strong>「メッセージソース」を「ソースデータ解析」に切り替え</strong>、webhook 「データ受信時」のノード出力をソースデータとして選択すれば、これらのパラメータを**メッセージ本文として自動的に送信できます。**