配送日時指定アプリなど、外部アプリでお客様に指定いただいたお届け日に合わせて、定期購買の次回以降のお届け予定日を調整できます。固定日設定の有無にかかわらず対応できます。
定期購買アプリは、初回お届け日を「初回注文日＋一般設定の『注文されてから届くまでの最短日数（注文日を除く）』」で計算します。外部アプリでお客様にお届け日を指定させている場合でも、その実際の指定日は次回以降の計算には使われません。
そのため、外部アプリで受け付けた実際のお届け日を基準に次回以降も届けたい場合は、Shopify Flow と公開APIを組み合わせて、次回お届け予定日を上書きします。
ポイント
この方法は、次回お届け予定日を自前のロジックで計算し、変更するものです。そのため、アプリの固定日ルールや間隔日数の仕様に合わせる必要はありません。ストアが「こう届けたい」という形を、Flow側で自由に計算して構いません。 後述の実装パターンは、あくまでよくある例です。
外部の配送日時指定アプリが、注文にカスタム属性（例：
配送希望日）を付与していること（Flowから実際のお届け日を読み取れる必要があるため）Shopify のプランが Grow プラン以上であること（Shopify Flow の「HTTPリクエスト送信」アクションを利用するため）
定期購買アプリのプランが ENTERPRISE プランであること（公開APIを利用するため）
トリガー：定期購買アプリの初回注文系トリガー（契約ID・購入周期などが渡されます）
コードを実行（JavaScript）：外部アプリの実お届け日をもとに、次回お届け日を計算する（※必要に応じて。下記例のAでは使いません）
HTTPリクエストを送信：公開APIの
subscriptionContractUpdateDeliveryDateを実行し、2で算出した日付で次回お届け予定日を上書きする
以下は実機で動作を確認した設定です。
HTTP method：
POSTHeaders：
x-shop：{{shop.myshopifyDomain}}x-api-key：公開APIキー（Flowのシークレットに登録して参照）Content-Type：application/jsonx-api-type：external
Body（
dateとidは、後述のとおり「変数を追加」で挿入します）：
idにはトリガーの契約ID、dateには後述のA／Bで算出した日付を渡します。以降は、固定日設定の有無でパターンが分かれます。ご利用のパターンのFlowファイル（添付）をインポートしてご利用ください。
初回に届いた「注文日→お届け日」の間隔（リードタイム）のまま、次回以降も届けるパターンです。「コードを実行」は使わず、HTTPリクエストのBody内のLiquidで計算まで完結します。
Bodyに以下のLiquidを設定します（初回の「注文日→配送希望日」の差分を、次回の基準日に加算）。
{%- assign new_date = "" -%}
{%- assign delivery_time_value = "" -%}
{%- for customAttributes_item in order.customAttributes -%}
{%- if customAttributes_item.key == '配送希望日' -%}
{%- assign order_date = order.createdAt | date: "%Y-%m-%d" | date: "%s" -%}
{%- assign delivery_date = customAttributes_item.value | date: "%s" -%}
{%- assign date_parts = nextBillingDate
| replace: "年", "-" | replace: "月", "-" | replace: "日", ""
| replace: ":00頃", "" | replace: " ", " 00:00:" -%}
{%- assign base_date = date_parts | date: "%Y-%m-%d" | date: "%s" -%}
{%- assign diff_seconds = delivery_date | minus: order_date -%}
{%- assign new_timestamp = base_date | plus: diff_seconds -%}
{%- assign new_date = new_timestamp | date: "%Y-%m-%d" -%}
{%- endif -%}
{%- if customAttributes_item.key == '配送時間帯' -%}
{%- assign delivery_time_value = customAttributes_item.value -%}
{%- endif -%}
{%- endfor -%}
{
"query": "mutation UpdateDelivery($id:String!, $date:Date!) { subscriptionContractUpdateDeliveryDate(subscriptionContractId: $id, nextDeliveryDate: $date) { subscriptionContractId } }",
"variables": {
"id": {{ subscriptionContractId | json }},
"date": {{ new_date | json }}
}
}※nextBillingDate は 2025年5月1日 9:00頃 のような形式で渡されるため、上記の replace で日付に整形しています。実際に渡ってくる値に合わせて調整してください。
実お届け日を起点に、次回以降は毎月決まった日（固定日）に届けるパターンです。「コードを実行」で次回お届け日を算出し、その結果をHTTPリクエストの date に渡します。
「コードを実行」に以下を設定します。
（例：実お届け日 9/28・周期1ヶ月・固定日20日 → 10月 → 10/20）
算出した nextDeliveryDate を、共通のHTTPリクエストのBodyの date に渡します。
この運用は、契約作成後に公開APIで次回お届け予定日を変更する仕組みです。
Bの固定日は、契約側の設定でトリガー・注文からは取得できないため、コード内の
fixedDayに直接指定します（プランごとにFlowを分ける運用が明快です）。導入時は、必ずテスト環境・テスト契約で実際の出力を確認してからご利用ください。
仕組みの詳細やゼロから作る場合は、参考：初回注文の「注文日→配送希望日」の間隔を、定期購買の次回以降の注文に引き継ぐ方法