オーダー一覧取得と更新・再発行の自動判定

ページ更新日：2026/10/12 ／ 仕様変更の履歴 ／ BASE URL https://www.slogical.co.jp/ssl/api/v1/

オーダー一覧取得（GET /ssl/api/v1/orders）

過去の注文を一覧で取得します。結果は注文 ID の降順（新しい順）で返されます。
ページングや検索条件（注文日・コモンネーム等）をクエリパラメータで指定できます。
特定のコモンネームに対して「新規発行・更新・再発行」のどれを実行すべきかを判定したい場合は、GET /ssl/api/v1/orders?common_name_exact=<CN>&per_page=1 を実行してください。コモンネームの完全一致で最新のご注文 1 件を取得でき、そのご注文に付く recommended_operation（次に必要な操作）・order_state（ご注文の状態）・残日数から、そのまま自動判定できます（詳細は下記「更新・再発行の自動判定」）。
※ order.expire は契約期限ではありません（満了日指定でご注文いただいた場合のみ値が入る、ご注文時の控えです。詳細は「レスポンス形式」の order フィールド説明をご参照ください）。
なお、更新・再発行の対象をまとめて抽出する場合は、専用の GET /ssl/api/v1/expiry（満了間近CN一覧の取得）をご利用いただくと、残日数付きで満了の近い順に取得できるため簡便です。

# 全件取得（新しい順）
curl -i "https://www.slogical.co.jp/ssl/api/v1/orders?page=1&per_page=30" \
  -H "Authorization: ApiKey <YOUR_API_KEY>"

# コモンネームで絞り込み（部分一致）
curl -i "https://www.slogical.co.jp/ssl/api/v1/orders?common_name=www.example.com" \
  -H "Authorization: ApiKey <YOUR_API_KEY>"

# コモンネームで絞り込み（完全一致）— 自動化ではこちら
curl -i "https://www.slogical.co.jp/ssl/api/v1/orders?common_name_exact=shop.example.com" \
  -H "Authorization: ApiKey <YOUR_API_KEY>"

# 対象コモンネームの最新のご注文 1 件だけ取得（更新・再発行の判定用）
curl -i "https://www.slogical.co.jp/ssl/api/v1/orders?common_name_exact=www.example.com&per_page=1" \
  -H "Authorization: ApiKey <YOUR_API_KEY>"

※ common_name は部分一致のため、たとえば common_name=shop.example.com は my-shop.example.com のご注文にも一致します。自動化で対象のご注文を一意に特定する場合は、必ず common_name_exact をご利用ください。
※ common_name_exact に空文字や使用できない文字（英数字・.・-・_・* 以外）を指定した場合は 400 エラーになります。条件を黙って無視して全件を返すことはありません（誤った注文を対象にした自動処理を防ぐためです）。大文字小文字は区別しません。

レスポンス例：

{
  "status": "OK",
  "is_sandbox": false,
  "total": 2,
  "page": 1,
  "per_page": 30,
  "orders": [
    {
      "order": {
        "id": 12345,
        "ssl_type": "ra01",
        "months": "",
        "expire": "",
        "csrinfo_cn": "www.example.com",
        "csrinfo_bit": "2048",
        "sans": "",
        "hash_algorithm": "full-sha2",
        "www_option": "a",
        "ev_jp_corp_name": "",
        "is_update": "n",
        "created": "2026-02-01 10:00:00"
      },
      "product_name": "RapidSSL 1年",
      "digicert_order_id": 67890,
      "digicert_order_till_gmt": "2027-02-01",
      "digicert_cert_valid_till_gmt": "2026-12-01",
      "digicert_status": "issued",
      "order_state": "issued",
      "recommended_operation": "reissue",
      "recommended_operation_reason": "cert_expires_before_contract",
      "newer_order_pending": false,
      "is_latest_for_cn": true,
      "days_to_contract_expiry": 155,
      "days_to_cert_expiry": 93
    },
    {
      "order": {
        "id": 12346,
        "ssl_type": "rw01",
        "months": "",
        "expire": "",
        "csrinfo_cn": "*.example.com",
        "csrinfo_bit": "2048",
        "sans": "",
        "hash_algorithm": "full-sha2",
        "www_option": "n",
        "ev_jp_corp_name": "",
        "is_update": "n",
        "created": "2025-05-01 10:00:00"
      },
      "product_name": "RapidSSL ワイルドカード 1年",
      "digicert_order_id": 67891,
      "digicert_order_till_gmt": "2026-05-01",
      "digicert_cert_valid_till_gmt": "2026-05-01",
      "digicert_status": "expired",
      "order_state": "expired",
      "recommended_operation": "renew",
      "recommended_operation_reason": "contract_expired",
      "newer_order_pending": false,
      "is_latest_for_cn": true,
      "days_to_contract_expiry": -121,
      "days_to_cert_expiry": -121
    }
  ]
}

※ digicert_cert_valid_till_gmt（証明書有効期限）は、DigiCert にて証明書が発行済みの場合のみ値が入ります。order_status が pending などの未発行状態では空文字になります。
※ order.months / order.expire はご注文時のリクエスト値の控えであり、契約・証明書の満了日ではありません。年単位（certificate.years）のご注文ではいずれも空文字になります。満了日は digicert_order_till_gmt（契約満了日）／digicert_cert_valid_till_gmt（証明書有効期限）をご参照ください。
※ digicert_order_till_gmt / digicert_cert_valid_till_gmt は、DigiCert 以外の認証局の商品（サイバートラスト系など、ウェブサイトからのご注文分）では空文字になります。

更新・再発行の自動判定（recommended_operation）

各ご注文には、そのコモンネームについて次に必要となる証明書操作の判定結果が付きます。
GET /ssl/api/v1/expiry（満了間近CN一覧の取得）の「満了 90 日以内」という抽出条件とは切り離しており、現時点の契約満了日と証明書有効期限だけから renew（更新）か reissue（再発行）かを常に返します。実際に何日前に申請するかは days_to_contract_expiry / days_to_cert_expiry をご覧のうえ、御社の運用ルールでご判断ください。

判定根拠（recommended_operation_reason）：

※ recommended_operation_reason が judgement_unavailable の場合、is_latest_for_cn と newer_order_pending の値は信用しないでください。判定に必要な集計自体ができていないため、両方とも false（＝それぞれ「最新ではない」「後続の申請はない」と読める値）が入りますが、実際にそうであるとは限りません。この場合は recommended_operation: "unknown" のみを見て、自動処理を停止してください。

自動化での使い方（例：満了 30 日前から申請する運用の場合）：

GET /ssl/api/v1/orders?common_name_exact=<CN>&per_page=1

total が 0 または キー自体が無い → 新規発行（POST /orders）
orders[0].recommended_operation == "none"              → 何もしない（申請中・より新しい注文あり）
orders[0].recommended_operation == "renew"
    && days_to_contract_expiry <= 30                   → 更新（POST /orders, is_update=y）
orders[0].recommended_operation == "reissue"
    && days_to_cert_expiry <= 30                       → 再発行（POST /orders/{id}/reissue）
orders[0].recommended_operation == "unknown"           → エラーとして停止（人手で確認）

※ per_page=1 は「そのコモンネームの最も新しいご注文」を返します（注文 ID の降順のため）。更新のご注文が登録されると、通常はその新しいご注文が order_state: "accepted"（＝recommended_operation: "none"）として先頭に表示されます。再発行は、状態の反映後に order_state: "reissue_pending" となります。いずれも排他制御や反映遅延の影響を受けますので、下記「自動化を安全に運用するための注意」を必ずご確認ください。
※ recommended_operation は「契約と証明書のどちらが先に満了するか」だけで決まります。契約満了も近い時期（例：契約 40 日・証明書 30 日）は reissue と判定されますが、この場合は再発行しても新しい証明書の期限は契約満了日までとなります。無駄な再発行を避けたい場合は、days_to_contract_expiry が一定日数以下なら更新を優先する、といった条件を御社側で追加してください。
※ days_to_* の日付境界は 日本時間の午前 9 時です（満了日を UTC の 0:00 として解釈しているため）。日本時間の 0:00〜9:00 の間は、当日満了の契約が「残り 1 日」と表示されます。マイページの満了一覧 CSV・満了通知メールと同じ計算方法に揃えているための仕様です。満了日そのもの（digicert_order_till_gmt / digicert_cert_valid_till_gmt）は影響を受けませんので、厳密な日数が必要な場合はそちらからご計算ください。
※ 判定に使う満了日は認証局と同期したもので、通常は 1 日 1 回（深夜）更新されます。

自動化を安全に運用するための注意

判定は取得した時点のスナップショットです。API 側で「同じコモンネームについて二重に申請できない」ようロック（排他制御）は行っておりませんので、次の点にご留意ください。

• 同一コモンネームの処理は直列に実行してください。 複数のワーカーやジョブが同じコモンネームを同時に処理すると、どちらも「更新が必要」と判定して二重にご注文される可能性があります。
• 申請 API の結果が不明なとき（タイムアウト・通信断など）は、そのまま再送しないでください。 まず GET /ssl/api/v1/orders?common_name_exact=<CN>&per_page=1 を取り直し、order_state が accepted / processing / reissue_pending になっていないかをご確認ください。なっていれば申請は受理済みです。
  再取得しても状態が変わっていない（issued のままなど）場合でも、「申請は失敗した」と判断して自動再送しないでください。 状態の反映が遅れているだけの可能性があります。自動処理はいったん停止し、翌日の同期をお待ちいただくか、弊社までお問い合わせください。
• accepted / processing が長く続く場合は警告してください。 通常は数営業日以内に issued へ進みます。目安として 7 日以上変化がない場合は、ドメイン認証（DCV）が未完了などの可能性がありますので、自動処理を止めて order.created とあわせてご確認いただくか、弊社までご連絡ください。
• 再発行の直後は状態の反映に遅延が生じることがあります。 再発行 API の成功後、弊社側では認証局の状態を即時に取り込みますが、認証局側の反映が遅れた場合は最大で翌日まで order_state が issued のまま残ることがあります。同じコモンネームへ短時間に繰り返し再発行を実行しない運用をおすすめします（再発行申請中の重複申請は、通常は認証局側でも拒否されます）。

※ サンドボックス用 API キーでは、コモンネーム www.example.com の発行済みダミー 1 件を返します（common_name_exact も効くため、0 件＝新規発行の分岐も動作確認できます）。ダミーの満了日は実行時刻を基準に「契約＝約 2 年後／証明書＝約 90 日後」で組み立てるため、recommended_operation は常に reissue になります。固定値ではありませんので、テストで値を突き合わせる場合はご注意ください。
※ 同一ドメインを大文字・小文字の異なる表記（例 WWW.example.jp と www.example.jp）で複数回ご注文いただいている場合、GET /ssl/api/v1/expiry 側では表記ごとに別のコモンネームとして集計されるため、newer_order_pending の値が本エンドポイントと食い違うことがあります。GET /orders 側は大文字小文字を区別せず同一ドメインとして扱います。表記を揃えてご注文いただくことを推奨します。