QuotWayのAPIとWebhookで作れるもの：基幹システム・CRM連携の6つの例

QuotWayに、公開のREST APIと署名付きの送信Webhookが加わりました。Enterpriseプランで利用でき、14日間の無料トライアル中も使えます。この2つを組み合わせると、誰も数字を打ち直すことなく、ほかのシステムが見積の動きを追えるようになります。バイヤーが見積を承認した瞬間に基幹システム（ERP）がそれを知り、CRMの商談には実際に合意した金額が表示され、ヘッドレスのストアフロントや営業用アプリから見積依頼を送れ、社内の承認依頼はチームがふだん使っている場所に届きます。

ただし、APIが価格を決めることはありません。APIはバイヤーの依頼を記録し、チームがすでに価格を付けた提案を送るだけです。価格、下限価格、承認ポリシーはQuotWayの中にあり、チームが管理します。

この記事では、作れるもの6つとそれぞれの注意点、APIがこのように設計されている理由、そしてあらゆる見積アプリのAPIに確認すべき質問を紹介します。リファレンスはAPIドキュメントにあり、ここに書いた事実はすべて2026年9月30日時点のドキュメントと一致しています。

利用できるもの

構成要素	できること
api.quotway.com のREST API v1	見積の読み取り（明細、合計、イベント、PDF、分析）、見積依頼の作成、メッセージの投稿、チームが保存済みの提案の送信
送信Webhook	25種類の見積イベントについて署名付きのHTTPSリクエストを送信。新しい依頼から、提案、再見積、承認、変換、支払いまで、さらに社内承認のすべての判断
イベントフィード	GET /v1/events：直近30日間のイベントを順番どおりに取得でき、受信側が取りこぼしたものに追いつける
キー	スコープ付き（read_quotes、read_customer_data、read_analytics、write_quotes、manage_webhooks）、有効期限とIP許可リストは任意、ロール時は24時間の重複期間あり。開発ストア向けには qw_test_ キー
仕様	https://api.quotway.com/openapi.json のOpenAPI 3.1。Postman、Insomnia、コードジェネレーターに取り込める

キーはストアの管理者が「設定 → 連携 → APIキー」で作成します。制限はキーごとに毎分120リクエスト、ストアごとに300です。

1. 取引が合意した瞬間を基幹システムに伝える

イベント： quote.accepted、quote.partially_accepted、quote.converted · スコープ： read_quotes

バイヤーが承認すると、Webhookがすぐにエンドポイントへ届きます。ハンドラーはそれを検証して 200 を返し、見積全体を取得して、基幹システムがその取引のために持つ販売レコードを作成・更新します。見積番号、バイヤーの会社、合意した明細、合計です。見積がShopifyの下書き注文になると、下書き注文ごとに1回 quote.converted が発火し、基幹システムが注文の横に保存できるリンクが届きます。その変換を下書き注文1件きっかりに保つ仕組みは、それだけで一つのエンジニアリングの話です。

注文そのものは、ほかの注文と同じ経路、つまり既存のShopifyコネクタで基幹システムに届けるべきです。変換された下書き注文には見積の参照が載っているので、両者はそこで結びつきます。Webhookは注文の背後にある交渉を加えるもので、注文の同期を置き換えるものではありません。どのシステムがどの項目を書くべきかは、基幹システム・CRM・PIMの連携パターンで整理しています。

公式のStandard Webhooksライブラリを使ったハンドラーです。

import express from "express";
import { Webhook } from "standardwebhooks";

const wh = new Webhook(process.env.QUOTWAY_WEBHOOK_SECRET); // "whsec_…"
const app = express();

// Keep the body raw for this route - verification needs the exact bytes.
app.post("/hooks/quotway", express.raw({ type: "application/json" }), async (req, res) => {
  let event;
  try {
    event = wh.verify(req.body.toString("utf8"), req.headers);
  } catch {
    return res.status(400).send("Invalid signature");
  }

  const eventId = req.headers["webhook-id"];
  if (await alreadyProcessed(eventId)) return res.sendStatus(200);

  await enqueueForProcessing(eventId, event); // fetch event.data.url and upsert, in the background
  res.sendStatus(200);
});

注意点： 配信は少なくとも1回で、順番どおりではありません。同じイベントが2回届くこともあり、1時間後の再試行はその時点の見積の状態を運びます。そのため、webhook-id ヘッダーで重複を除き、data.sequence で順番を決め、基幹となる記録システムに書き込むものについては、ペイロードの要約を信じるのではなく data.url から見積を取得してください。

2. CRMの商談を、実際に合意した金額に保つ

イベント： 交渉と結果のイベント · スコープ： read_quotes（CRMにバイヤーの連絡先が必要な場合は read_customer_data も）

見積を追うCRMの商談に必要なのは2つです。正しいステージと、正しい金額です。ステージはそのまま対応します。

QuotWayのイベント	商談のステージ
quote.created	新規の依頼
quote.proposal_sent	提案送付済み
quote.countered	交渉中
quote.merchant_approval.requested	社内確認中
quote.accepted	成約
quote.partially_accepted	一部成約。未決定の明細は保留中で、まだ交渉が続いている
quote.declined、quote.buyer_approval.rejected	失注
quote.expired	期限切れ。フォローする価値があり、失注とは限らない
quote.order_completed	支払い済み

CRMがよく間違えるのは金額です。一部承認の場合、見積の total は当初の提示額の全体を示したままです。それは提示した金額で、書き換えられることはありません。代わりに totals.headline を保存してください。これが行動の基準にすべき数値で、totals.headline_mode がなぜその数値なのかを示します（none または full なら提示額の合計、decided または open なら承認された合計）。モードが open のとき、still_open_total はまだ交渉中の金額なので、商談には合意した部分と、バイヤーがまだ判断していない部分の両方を表示できます。

注意点： 一部承認でバイヤーが選ばなかった明細は、辞退されたのではなく保留中で、まだ交渉が続いています。それを「失注」に対応させると、パイプラインを少なく数え、まだ断っていないバイヤーにフォローを送ることになります。

3. ヘッドレスのストアフロントや営業用アプリから見積依頼を受け取る

エンドポイント： POST /v1/quotes · スコープ： write_quotes

Hydrogenのストアフロント、店頭カウンター用のアプリ、営業担当者のツールから、オンラインストアの「見積を依頼」ボタンと同じように見積依頼を送れます。キーはサーバー側に置いたまま、サーバーから送ります。

curl https://api.quotway.com/v1/quotes \
  -H "Authorization: Bearer $QUOTWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 9d3e1f7a-5b2c-4e8d-a1f0-6c7b8a9d0e12" \
  -d '{
    "buyer": { "email": "buyer@example.com", "name": "Dana Ortiz", "company_name": "Acme Restaurant Group" },
    "lines": [ { "variant_id": "gid://shopify/ProductVariant/4455667788", "quantity": 100, "requested_price": "11.50" } ],
    "notes": "Delivery to our Denver kitchen, please."
  }'

依頼はストアフロントと同じ受付を通ります。ターゲティングルールが依頼を受け付けるかどうかを決め、見積フォームのカスタム項目が検証され、自動化ルールが実行され、チームにはいつもの「新しい見積」メールが届きます。requested_price はバイヤーの希望価格にすぎず、チームが提示する価格はQuotWayの中で決まります。Shopifyの customer_id を渡すと、QuotWayはその顧客の実際のタグとB2Bの会社への所属を確認し、顧客が会社の所在地の連絡先であれば、ストアにログインしたバイヤーの場合とまったく同じように、見積は会社に紐づいたものになります。

注意点： 201 のレスポンスは submitted を示しますが、自動化ルールはすぐに新しい見積に作用します。自動送信のルールが提案を送ることも、自動辞退のルールが辞退することもあります。作成したばかりの見積がまだ submitted だと決めつけず、quote.proposal_sent、quote.declined、quote.assigned を受信するか、行動する前に見積を取得し直してください。また、Idempotency-Key は必ず送ってください。見積が作成されたあとで接続が切れても、再試行は重複した依頼を作らず、同じレスポンスを返します。

4. 承認依頼（稟議）を、チームがふだん使う場所に届ける

イベント： quote.merchant_approval.requested、.granted、.rejected

しきい値を超える値引きや高額の見積など、提案に社内の承認が必要になると、quote.merchant_approval.requested が発火します。小さな中継処理があれば、それを承認者が見ているチャンネルへのメッセージに変え、見積番号とQuotWayで開くためのリンクを添えられます。.granted と .rejected で一連の流れが閉じます。署名付きのWebhookを受け取れるシステムなら何でもこれができます。自社のエンドポイントでも、連携プラットフォームの汎用Webhookトリガーでも構いません。

承認そのものは、引き続きQuotWayの中で、承認ポリシーに従って行われます。メッセージは通知であって、押せば承認されるボタンではありません。

注意点： Webhookのペイロードには、設計上バイヤーの氏名、メールアドレス、自由記述のテキストが含まれません。そのため、メッセージには振り分けに必要なもの（見積番号、状態、合計）だけがあり、個人的な情報はありません。承認者がそれ以上の情報を必要とする場合は、適切なスコープを持つキーで見積を取得してください。そして、バイヤーの詳細を共有チャンネルに貼り付ける前によく考えてください。

5. 見積の指標をBIツールに取り込む

エンドポイント： GET /v1/analytics/summary · スコープ： read_analytics

curl -G https://api.quotway.com/v1/analytics/summary \
  -H "Authorization: Bearer $QUOTWAY_API_KEY" \
  --data-urlencode "period=week" \
  --data-urlencode "limit=4"

QuotWayの分析ダッシュボードと同じ集計済みの指標、つまり件数、承認額と変換額、パイプライン、応答時間を、日・週・月単位で、UTCとストアの基本通貨で返します。これをデータウェアハウスやスプレッドシートに取り込む定期ジョブが、連携のすべてです。キーには個人データへのアクセスが一切不要です。

6. 別のシステムで確認したあとに提案を送る

エンドポイント： POST /v1/quotes/{id}/send-proposal · スコープ： write_quotes

価格はQuotWayで付けつつ、提案をいつ送るかは別のシステムに決めさせたいチームもあります。利益率や在庫を確認する基幹システム、商談の準備完了を示すCRMのステップ、朝9時にその日の提案をまとめて送るジョブなどです。send-proposal は、チームが提案エディターですでに保存した提案を、管理画面とまったく同じチェックを経て送ります。見積が提案を受けられる状態であること、会社に紐づいた見積ではカタログ価格がShopifyから読み直されること、下限価格を下回る明細があると、呼び出しで明示的に確認しない限り（管理画面が求めるのと同じ確認です）送信が止まること、そして承認ポリシーが適用される場合は、提案が送られずに承認待ちになることです。

注意点： 誰も提案を保存していなければ、送るものはありません。呼び出しは 409 no_staged_proposal を返します。APIはチームが付けた価格を送るだけで、価格を付けることはありません。

このように作られている理由

APIを形づくる判断は6つあり、どれもAPIの振る舞いを信頼できる理由になっています。

1. 価格を設定しない。 価格は見積ツールが利益を生むか失うかの分かれ目なので、チームの手元に残します。下限価格、承認ポリシー、提案エディターは、APIから届いたものを含むすべてに適用されます。価格を付ける、明細を編集する、バイヤーに代わって承認・辞退する、見積を下書き注文へ変換する、といったエンドポイントはありません。
2. Webhookに個人データを含めない。 ペイロードにあるのは識別子、イベントの種類、見積の番号、状態、通貨、合計だけで、バイヤーの氏名、メールアドレス、電話番号、住所、メッセージは含まれません。バイヤーの詳細はAPIからのみ、しかも read_customer_data スコープを持つキーでのみ取得できます。設定を誤ったエンドポイントでも、そもそも送られていないものは漏らせません。
3. WebhookはStandard Webhooksの仕様に従う。 署名のヘッダーは標準のものなので、自作のコードではなく公式の standardwebhooks ライブラリで検証できます。シークレットのローテーション中は、24時間にわたって配信が両方のシークレットで署名されるため、切り替えの間も失敗しません。
4. 配信は再試行され、あとから取り直せる。 失敗した配信は、最初の試行を含めて最大8回、約3.7日間にわたって試みられます。失敗し続けるエンドポイントは無効化され、チームにメールが届きます。取りこぼしたものも GET /v1/events に30日間、順番どおりに残っています。
5. すべての書き込みが冪等。 すべての POST は24時間有効な Idempotency-Key を受け付けるため、再試行したリクエストが2つ目の見積を作ったり、提案を2回送ったりすることはありません。
6. エラーが具体的で安定している。 エラーはRFC 9457に従い、not_eligible、below_price_floor、insufficient_scope といった安定した code を持ちます。それぞれがエラーのリファレンスの該当項目にリンクしているので、連携は文章を解析する代わりにコードで分岐できます。

まだできないこと

• パッケージ化されたコネクタはありません。 Zapierのディレクトリにアプリはなく、MCPサーバーもなく、HubSpot、Salesforce、Klaviyoとの組み込みの連携もありません。これらのシステムとは、APIとWebhookを通じて連携できます。
• SDK、GraphQL API、サンドボックスはありません。 OpenAPIの仕様はほとんどのツールに取り込めます。qw_test_ キーはShopifyの開発ストアで動作し、そのストアの実際のデータを対象にします。
• APIでの価格設定、明細の編集、承認、変換はできません。 前述のとおり、設計上の判断です。

あらゆる見積アプリのAPIに確認すべき質問

どのアプリを評価する場合でも、次の質問で、その上に構築できるAPIと料金ページの1行にすぎないAPIを見分けられます。

• ドキュメントは公開されていて、取り込める機械可読の仕様があるか。
• Webhookは署名されているか。独自のコードではなく標準のライブラリで検証できるか。
• エンドポイントが受け取れなかった配信はどうなるか。どれだけの期間再試行され、再送できるか。
• 再試行したリクエストが重複を作ることはあるか。書き込みは冪等キーを受け付けるか。
• Webhookのペイロードに顧客データは含まれるか。キーのスコープを絞って、顧客データを一切読めないようにできるか。
• APIは価格を変更できるか。できるなら、下限価格と承認は引き続き適用されるか。
• 互換性のない変更の前に、どれだけ前もって知らされるか（QuotWayのAPI利用規約は少なくとも6か月前を約束しています）。

データの扱い、APIのバージョン、サーバー側で強制されるものなど、アプリの評価のほかの部分はShopify BtoBアプリの評価方法にまとめています。

はじめ方

1. ストアがEnterpriseプラン、または14日間のトライアル中であることを確認します。プランの詳細は料金にあります。
2. 「設定 → 連携 → APIキー」で、必要なスコープだけを付けたキーを作成し、API利用規約に同意します。
3. クイックスタートに沿って進めます。/v1/ping でキーを確認し、見積を一覧し、依頼を作成します。約10分です。
4. 「設定 → 連携 → Webhook」でWebhookのエンドポイントを追加し、テストのpingを送ります。

製品としての説明はAPIとWebhookの機能ページにあります。

よくある質問

QuotWayにAPIはありますか？

はい。QuotWayには api.quotway.com の公開REST API（v1）と署名付きの送信Webhookがあり、Enterpriseプランで利用できます。14日間の無料トライアル中も使えます。見積の読み取り、見積依頼の作成、メッセージの投稿、チームがすでに価格を付けた提案の送信ができますが、価格を設定することはありません。

QuotWayのAPIとWebhookはどのプランに含まれますか？

Enterpriseプラン（$199/月）です。14日間の無料トライアル中のストアでも両方を使えます。ストアが下位のプランに移った場合、キーとWebhookのエンドポイントは残りますが、Enterpriseに戻るまで一時停止されます。

ヘッドレスのShopifyストアフロントから見積を作成できますか？

はい。ストアフロントのサーバーから POST /v1/quotes を使います。依頼はオンラインストアの見積ボタンと同じターゲティングルール、カスタム項目の検証、自動化ルールを通り、チームが価格を付ける依頼として届きます。

QuotWayのWebhookに顧客データは含まれますか？

いいえ。Webhookのペイロードに含まれるのは、識別子、イベントの種類、見積の番号、状態、通貨、合計だけで、氏名、メールアドレス、電話番号、住所、メッセージは含まれません。バイヤーの連絡先は、read_customer_data スコープを持つキーを使ったAPIからのみ取得できます。

QuotWayのWebhookの署名はどう検証しますか？

QuotWayはStandard Webhooksの仕様に従っているので、お使いの言語向けの公式 standardwebhooks ライブラリを使います。生のリクエストボディ、webhook-id・webhook-timestamp・webhook-signature の各ヘッダー、そしてエンドポイントの whsec_ シークレットを渡してください。検証に失敗したものはすべて拒否します。

APIで価格を設定したり、バイヤーの代わりに見積を承認したりできますか？

いいえ。価格を付ける、明細を編集する、バイヤーに代わって承認・辞退する、見積を変換する、といったエンドポイントはありません。APIで提案を送ると、チームが保存した提案が、管理画面と同じ下限価格と承認のチェックを経て送られます。

QuotWayはZapierやHubSpotと連携できますか？

APIとWebhookを通じてなら可能です。たとえば、連携プラットフォームの汎用Webhookトリガーに送るWebhookや、CRMを更新する自社のサービスです。現時点で、Zapierのディレクトリにアプリはなく、HubSpotとのネイティブ連携もありません。

出典

2026年9月30日に確認したQuotWayのAPIドキュメント：

• APIの概要、クイックスタート、認証、キー、スコープ
• Webhook：イベントの一覧、ペイロード、署名、再試行、順序
• 見積の作成、メッセージと提案、見積オブジェクト、イベント、分析、レート制限
• エラーとOpenAPI仕様
• API利用規約