APIの変更履歴

2026年10月

• 仕様書 2026-10-24

  数値を number として公開

  636 の数値フィールドが integer|string として公開されていたのを number（integer）に統一しました。APIが数値を文字列で返すことはありません。リクエストでは引き続き数字の文字列も受け付けます。

• 追加 2026-10-24

  ユーザーのプロフィールを変更するAPI

  PATCH /api/v1/me で表示名・言語・タイムゾーンを、POST /api/v1/me/avatar でプロフィール画像を変更できます。スコープは user.profile.write です。受け付けられない項目が1つでもあれば、プロフィールは変更されません。

• 仕様書 2026-10-24

  /sales/kpis と /sales/trend の2つの形を公開

  storeId を指定すると店舗の形（revenue, transactionCount など）、指定しないとビジネスアカウントの形（totalRevenue など）を返します。これまで仕様書には後者しか載っていなかったため、両方を oneOf で公開しました。

• 仕様書 2026-10-24

  エラー応答と 401/403 を仕様書に掲載

  トークンが必要なすべての操作に 401 と、必要なスコープを示す 403 を掲載しました。成功時のステータス（204 など）も実際の値で公開しています。動作の変更はありません。

• 要対応 2026-10-23

  Webhook の署名をシークレットで行うように修正

  Webhook の署名がドキュメントと異なりクライアントIDで行われていたのを、Webhook 登録時のシークレットで行うように修正しました。署名をクライアントIDで検証している場合は、シークレットに切り替えてください。あわせて receipt.created が新しい売上ごとに送信されるようになり、X-RR-Delivery は再送でも同じ値になりました。

• 仕様書 2026-10-23

  トークンだけが必要な操作を仕様書で明示

  スコープを問わずトークンが必要な操作（/me、デバイス、Webhook 管理など）に、スコープなしの security を付けました。security がない操作はトークン不要です。サイトのログインで使う /api/sns/crm/* とクリエイティブAPIは仕様書から外しました。

• 追加 2026-10-23

  お知らせ（投稿）の作成・管理API

  /api/v1/organizations/{organizationId}/posts で、下書き・予約を含む一覧、詳細、作成、部分更新、公開、アーカイブ、削除ができます。新しいスコープ store.posts.read / store.posts.write が必要です。

• 追加 2026-10-23

  Google ビジネスプロフィールのクチコミとインサイト

  /api/v1/google-business で、未返信のクチコミ一覧、返信、AI による返信案、店舗のインサイトを取得できます。スコープは sns.content.read / sns.content.write です。また、APIで変更した店舗情報と営業時間は、連携した Google のリスティングにも反映されるようになりました。

• 追加 2026-10-20

  トークン検証でビジネスアカウントIDを返却

  POST /api/v1/auth/verify の応答に organizationId を追加しました。ビジネスアカウントに紐づくトークンではそのID、ユーザーのトークンでは null です。項目の追加のみのため、既存のクライアントへの影響はありません。

• 要対応 2026-10-20

  取引・予約・顧客APIで店舗ロールを確認

  店舗に配置されていれば店舗のAPIをすべて使えた状態を改め、店舗ロールに応じて制限しました。スタッフは予約と当日の取引の閲覧、シフトリーダーは過去の取引の閲覧・予約の作成・枠の運用・顧客の検索、店長は顧客の変更まで行えます（日付は日本時間）。ビジネスアカウントのロールは従来どおりです。

• 追加 2026-10-13

  クーポンの取得・利用とお店からのメール設定

  ユーザーのクーポンの取得・利用・利用の取り消しができるAPIを追加しました（スコープ user.coupons.write）。断られた場合は理由を 409（already_used など）で返します。お店からのメールの受信設定も /api/v1/user/store-mail で読み書きできます。

• 要対応 2026-10-10

  レシートの保存・変更・削除に user.receipts.write が必要に

  ユーザーのレシートAPIの書き込み18操作（レシート、カテゴリ、ラベル、スキャン、明細、QRでの受け取り）が、user.receipts.read だけで実行できていました。user.receipts.write を追加し、これらに必須としました。移行のため、2週間は user.receipts.read でも受け付けます。

• 仕様書 2026-10-07

  パラメータの説明とエラー本文を仕様書に掲載

  書かれていたのに仕様書に出ていなかった32件のパラメータ説明を公開しました。4xx の本文は実際の形である ApiError（{ error }）として公開しています。400 はモデル検証の ProblemDetails も併記します。

• 要対応 2026-10-07

  ビジネスアカウントのロールは担当領域の店舗だけに

  どのビジネスアカウントのロールでも店舗APIの全領域を使えた状態を改め、ロールごとに全店舗を扱える領域を、Web画面と同じ範囲に限定しました。担当外の領域では、配置されている店舗だけを扱えます。

• 要対応 2026-10-07

  ビジネスアカウント単位のAPIは呼び出し元の店舗だけを返却

  店舗に配置されたユーザーが、他店舗の顧客・注文・売上・スタッフまで取得できていました。取引・注文・在庫・スタッフ・顧客は呼び出し元の店舗に絞り込み、商品は自店舗の価格だけを返して原価は返しません。ビジネスアカウントのロールと連携用トークンの結果は変わりません。購入履歴の取得件数の上限は200件になりました。

2026年9月

• 変更 2026-09-24

  レシート受け取りリンクの有効期限は最大7日

  POST /api/v1/transactions/{id}/claim-token の ttlMinutes に上限がありませんでした。10080分（7日）を超える値は 400 になります。指定なし・0以下は従来どおり1440分です。claimUrl はパス部分がトークンそのものなので、ログに出力しないでください。

• 変更 2026-09-24

  /api/v1/me の 403 に理由を追加

  /api/v1/me の 403 が空の本文で返っていました。ユーザーを含まないトークンには no_user_context、メンバーでないユーザーには not_a_member を返します。ステータスコードは変わりません。

• 要対応 2026-09-09

  店舗の売上を読むには店舗を運営するロールが必要に

  sales.read を持つトークンなら、店舗に配置されているだけで ?storeId= でその店舗の売上・顧客の離反スコア・アドバイスを読めていました。店舗を運営するロールが必要になりました。ビジネスアカウントに紐づくトークンは引き続き利用できます。あわせて、各操作が必要とするスコープを仕様書に掲載しました。