ZapierのPOST用Webhookの使い方と設定例

ZapierのWebhookは、外部サービスへPOSTリクエストを送る設定と、外部サービスからWebhookトリガーとして受け取る設定で見る場所が変わります。JSON、フォーム、XML、Custom Requestの違いも絡むので、ZapierのWebhook POST例を見ても、自分のZapにどれを当てはめればいいか迷いやすいですよね。

POST URL、Payload Type、Data、Headersの関係が分かると、設定ミスの切り分けがかなり楽になります。Webhooks by Zapierが無料プランでどこまで使えるのか、配列や入れ子データはどう考えるのかも含めて、私のほうで実務目線で整理しました。

ZapierのPOST用Webhook基本

ZapierでPOST用Webhookを使うときは、まず「Zapierがデータを受け取る側なのか」「Zapierから外部サービスへ送る側なのか」を分けて考えると迷いにくいです。同じWebhookという言葉でも、トリガーとアクションでは設定画面も役割も変わります。

ここでは、Webhookの基本、POSTリクエストの意味、Catch HookとCatch Raw Hookの違い、無料プランまわりの確認点を整理します。いきなり細かい設定に入るより、先に全体像を押さえるのが近道ですよ。

Webhookでできること

Webhookは、ざっくり言うとあるサービスで何かが起きたとき、その情報を別のサービスへ自動で送る仕組みです。Zapierでは、このWebhookを使って外部サービスからデータを受け取ったり、Zapの途中で別のURLへデータを送ったりできます。

Webhookで扱う主な流れ

メール通知に近い感覚で考えると分かりやすいかなと思います。あなたが毎回アプリを見に行かなくても、何かが起きたタイミングで必要なデータが送られてくる。これがWebhookの便利なところです。

ただし、Webhookは万能のボタンではありません。送るデータの形式、受け取るURL、認証情報、ヘッダーなどが相手サービスの仕様と合っていないと動きません。Zapierだけで完結する設定ではなく、相手側のAPI仕様もセットで確認するのが大事です。

POSTリクエストの役割

POSTリクエストは、外部サービスに対してデータを送るときによく使われるHTTP通信の方法です。ZapierのWebhooks by Zapierでも、POSTは「指定したURLへデータを渡す」用途で使います。

HTTPメソッドの基本的な違い

POSTで送る中身は、JSON、フォーム形式、XMLなどに分かれます。ZapierのPOSTアクションではPayload Typeを選び、Data欄にキーと値を入れていく形が基本です。たとえば名前、メールアドレス、注文番号のような項目を、相手サービスが求める名前に合わせて渡します。

ここでつまずきやすいのは、POSTなら何でも受け取ってもらえるわけではないという点です。相手のAPIがJSONを求めているのにフォーム形式で送ったり、Content-Typeヘッダーが不足していたりすると、400番台のエラーになることがあります。エラー文がざっくりしているサービスもあるので、送信形式の確認はかなり重要です。

Webhookトリガーの選び方

ZapierでWebhookを受け取ってZapを開始したい場合は、Webhooks by Zapierのトリガーを使います。代表的なのはCatch HookとCatch Raw Hookです。どちらもGET、POST、PUTのリクエストを受け取れますが、データの扱い方が違います。

トリガー選びの目安

多くの場合、最初はCatch Hookで十分です。Zapierが受け取ったJSONやフォームデータを項目ごとに分けてくれるので、後続ステップでメールアドレスや名前などを選びやすくなります。ノーコードで扱いやすいのはこちらですね。

一方で、相手サービスから送られてくるデータをそのまま確認したい、ヘッダーも含めて後で見たい、という場合はCatch Raw Hookが候補になります。API連携に慣れている人向けの選択肢に近く、最初から使うというより、通常のCatch Hookでうまく扱えないときに検討するくらいでよいかなと思います。

Catch HookとRaw Hook

Catch Hookは、Zapierが受け取ったリクエスト本文を解析して、後続ステップで使いやすい項目に分けてくれるトリガーです。たとえばJSONでfirst_nameやemailが送られてきた場合、それぞれをZapの中で選べるフィールドとして扱いやすくなります。

⚙️ Catch HookとCatch Raw Hookの違い

Catch Raw Hookは、受け取った本文をそのまま扱いたい場合に向いています。Zapierのヘルプでは、Catch Raw Hookのリクエスト本文は最大2MBという案内があります。添付ファイルや巨大なJSONをそのまま処理したい場合は、Zapier内で完結できるかを先に確認したほうが安全です。

また、Webhookの応答にも注意が必要です。ZapierのWebhookトリガーは通常、受信に対して200系のレスポンスを返しますが、細かいカスタムレスポンスを自由に作れる前提では考えないほうがよいです。相手サービスが「特定の文字列を返してほしい」という仕様の場合は、Zapierだけで対応できるか確認が必要です。

無料プランで使える範囲

ZapierのWebhookは便利ですが、無料プランでどこまで使えるかは特に確認しておきたいところです。調べた範囲では、Webhookをトリガーとして受ける機能と、Zapのアクションとして外部へWebhookを送る機能で、利用条件の案内が分かれる場合があります。

プラン確認で見るポイント

• ✅ Webhooks by Zapierをトリガーに使えるか
• ✅ POSTアクションを使えるか
• ✅ Zapのステップ数や実行回数の上限
• ✅ 無料トライアル中の扱い
• ✅ チームプランや有料プランでの制限差

特に、Zapierから外部APIへPOSTリクエストを送る用途は、有料プランが関係する可能性があります。一方で、Webhookを受け取ってZapを開始する機能については、公式ヘルプ上でFreeを含むプラン案内が出ているケースもあります。ここは時期によって変わる可能性があるので、正確な情報は公式サイトをご確認ください。

無料で試すなら、まずはWebhookトリガーでデータを受け取れるか、Zapのテスト画面でサンプルデータが表示されるかを見るのが現実的です。そのうえで、外部へPOST送信したい場合は、現在のプランでWebhooks by Zapierのアクションが使えるかを確認するとムダが少ないですよ。

ZapierのPOST用Webhook実践

ZapierのPOST用Webhookは、設定項目の意味が分かればそこまで怖くありません。大事なのは、URL、Payload Type、Data、Headersの4つを相手サービスの仕様に合わせることです。

ここでは、Zapierから外部サービスへPOST送信する流れを、実際に設定するときの順番で整理します。エラーになりやすいJSON、フォーム、認証、配列データも一緒に見ていきましょう。

POST送信の設定手順

Zapierから外部APIやWebhook URLへデータを送る場合は、ZapのアクションとしてWebhooks by Zapierを追加します。イベントではPOSTを選ぶのが基本です。GETは情報取得、POSTはデータ送信、とまず分けて考えるとスムーズですよ。

POST送信で見る設定項目

設定の流れは、まず送信先URLを入れ、Payload Typeを選び、Data欄に送信したい項目を入れます。たとえばフォームの回答をCRMへ送るなら、名前、メールアドレス、問い合わせ内容などを相手サービスの項目名に合わせて渡します。

テスト前には、Zapier内で前ステップのデータが正しく入っているか確認しておきましょう。空の値を送ると相手側でエラーになることがありますし、Webhookトリガー側でも空のリクエストは無視される場合があります。まず小さいデータでテストするのが安全です。

もしテストが失敗したら、Zapierだけを疑うのではなく、相手APIの仕様、必須項目、認証、ヘッダー、送信形式を順番に見ます。PostmanやRequestBinのような確認ツールで、実際にどんなリクエストが送られているかを見ると切り分けしやすいです。

JSONとフォームの違い

ZapierのPOSTでは、Payload TypeとしてJSONやFormを選べます。どちらもデータを送る形式ですが、相手サービスがどちらを受け付けるかはAPI仕様によって決まります。ここを勘で選ぶと、見た目は合っているのにエラーになることがあります。

Payload Typeの違い

JSONは、API連携でよく使われる形式です。項目名と値をセットで送り、入れ子のデータも表現しやすいのが特徴です。一方で、カンマや波括弧のミスがあると壊れやすいので、Custom RequestでJSONを直接書く場合はバリデーターで確認したほうがいいです。

Formは、URLエンコード形式とも呼ばれます。シンプルな入力フォームの内容を渡すようなケースでは扱いやすいです。ただし、複雑な配列や深い入れ子構造を送りたい場合は、FormよりJSONのほうが向いていることが多いです。

迷ったときは、相手サービスのAPIドキュメントでContent-Typeやリクエスト例を確認します。application/jsonと書かれていればJSON、application/x-www-form-urlencodedと書かれていればFormを選ぶのが基本です。正確な情報は公式サイトをご確認ください。

URLとデータ項目の入力

URL欄には、POSTリクエストを受け取る相手サービスのURLを入力します。Zapierのヘルプでは、URLパラメータを直接URL欄に足すより、Data欄へ分けて入力する方法が案内されています。管理しやすさを考えても、そのほうがミスは減りやすいです。

URLとData入力の見方

Data欄では、左側にキー、右側に値を入れます。左側は相手APIが期待している項目名なので、あなたが分かりやすい名前を自由に付ける場所ではありません。たとえば相手がemailを求めているなら、mail_addressに変えると受け取れない可能性があります。

右側には、前のステップで取得したデータを差し込めます。フォーム送信のメールアドレス、Google Sheetsの行データ、CRMの顧客IDなどを選べるイメージです。固定値を入れることもできますが、Zap実行ごとに変わる値なのか、毎回同じ値でよいのかは分けて考えましょう。

注意点として、Data欄を空にすると前ステップのすべてのフィールドが送られる場合があります。便利に見えますが、不要なデータまで渡ると相手側でエラーになったり、管理上のリスクが増えたりします。基本は必要な項目だけを明示して送るのがおすすめです。

ヘッダー認証の確認点

WebhookのPOST送信では、本文の中身だけでなくHeadersも大事です。Headersは、リクエストに添える追加情報のようなものです。特にContent-Typeと認証情報は、エラー原因になりやすいポイントです。

よく確認するヘッダー

たとえばJSONで送っているつもりでも、Content-Typeが不足していると相手APIが正しく解釈できないことがあります。Zapier Communityでも、配列を含むPOSTがうまくいかなかったケースで、Content-Typeヘッダーを追加して解決した例がありました。つまり、データ本体が正しくてもヘッダー不足で止まることがあるわけです。

認証は、Basic Auth欄で済む場合と、HeadersへAPIキーやBearerトークンを入れる場合があります。どちらを使うかは相手サービスの仕様次第です。Zapier側で勝手に判断してくれるものではないので、APIドキュメントの認証欄を見ながら設定します。

APIキーやトークンは、扱いに注意が必要です。共有画面やスクリーンショットにそのまま載せない、不要になったキーは無効化する、といった基本は守りたいところです。業務で使う場合は、最終的な判断は専門家にご相談ください。

Custom Requestの使い所

Custom Requestは、Zapierの通常のPOST、PUT、GETより柔軟にリクエストを作れる機能です。PATCHやDELETEを使いたい、かなり細かいヘッダーを指定したい、JSONをそのまま書きたいといった場面で候補になります。

Custom Requestを選ぶ目安

ただし、Custom Requestは便利な反面、Zapierが自動で整えてくれる範囲が狭くなります。Data欄に入力したJSONは、基本的にそのまま送られるものとして考えます。括弧や引用符のミス、余計なカンマがあると、そのままエラーになります。

初心者のうちは、まず通常のPOSTで組めないかを確認するのがよいです。相手サービスがシンプルなJSONやフォーム形式を受け付けるなら、通常POSTのほうが設定もテストも楽です。Custom Requestは、通常POSTでは表現しにくい要件が出たときの選択肢ですね。

Custom Requestを使う場合は、Postmanなどで成功するリクエストを先に作ってから、Zapierへ移す流れが現実的です。Zapier上だけで試行錯誤すると、エラーの原因がJSONなのか、ヘッダーなのか、認証なのか分かりにくくなります。

配列や入れ子データの注意

ZapierのWebhookでは、入れ子データや配列も重要なポイントです。入れ子とは、データの中にさらにデータが入っている形のことです。たとえば顧客情報の中に住所、注文情報の中に商品リストが入っているようなケースですね。

入れ子と配列の考え方

Zapierでは、二重アンダースコアを使って入れ子を表現できる場面があります。たとえばitem__priceのようにすると、JSONではitemの中にpriceが入る形に変換されるイメージです。Webhookアクション側では、Unflattenの設定が関係することもあります。

配列については、WebhookトリガーがJSONオブジェクトの配列を受け取ると、各オブジェクトを別々のZap実行として処理する場合があります。たとえば5人分のデータが配列で送られると、後続ステップが5回動くイメージです。これは便利ですが、意図せず大量実行になる可能性もあります。

一方で、配列を1つの親オブジェクトの中に包むと、Zapierが1回のZap実行として扱うケースがあります。つまり、配列を「複数件として処理したい」のか、「1つのまとまりとして処理したい」のかで送る形を変える必要があります。

複雑な配列や深い入れ子を外部APIへPOSTする場合は、通常POSTのData欄だけではうまく表現できないことがあります。その場合はCustom Requestを使うか、ZapierのDeveloper Platform、または中継用の自社APIを検討する流れになります。ここは無理にノーコードだけで押し切らないほうがいい場面です。

ZapierのPOST用Webhookまとめ

ZapierのPOST用Webhookは、外部サービスとZapierをつなぐ実用的な手段です。ただし、動くかどうかは「ZapierでPOSTを選んだか」だけでは決まりません。送信形式、URL、データ項目、ヘッダー、認証、配列の扱いまで合わせて見る必要があります。

✅ この記事全体の要点

1. Webhookは、サービス間でデータを自動送受信する仕組みです
2. Zapierでは、受信するWebhookトリガーと送信するWebhookアクションを分けて考えます
3. POST送信では、URL、Payload Type、Data、Headersの確認が基本です
4. JSONとFormは別物なので、相手APIの指定に合わせます
5. Content-TypeやAuthorizationなどのヘッダー不足はエラー原因になります
6. Custom Requestは柔軟ですが、JSONの書き方や認証設定を自分で正確に整える必要があります
7. 配列や入れ子データは、Zapの実行回数や送信形式に影響します

実践で詰まったら、いきなり全部を直そうとせず、まず小さいテストデータで確認するのがおすすめです。URLが正しいか、必須項目が入っているか、JSONかFormか、Content-Typeは合っているか。この順番で見るだけでも、かなり原因を絞れます。

Zapierはノーコード寄りのツールですが、WebhookはAPIの考え方が少し入ります。だからこそ、相手サービスの公式ドキュメントとZapierの公式ヘルプを見ながら進めるのが安全です。料金や利用条件、仕様は変わる可能性があるため、正確な情報は公式サイトをご確認ください。

記事作成にあたり参考にさせて頂いたサイト

• Send webhooks in Zap workflows
• Best way to easily test a webhook trigger for a Zap? | Zapier Community
• Trigger Zap workflows from webhooks
• POST Request to External API with attribute Arrays | Zapier Community
• How to get started with Webhooks by Zapier
• How to find out what a Zap’s webhook url is? | Zapier Community
• What are webhooks? | Zapier
• Zapier Webhook Response | Zapier Community
• Send webhook POST requests on a daily schedule
• How to send PHP FORM POST data to Zapier webhook: SOLUTION | Zapier Community

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。