Dynadot API は、お客様のシステムとシームレスに統合できるように設計されています。当社の API は、予測可能なリソース指向の URL を特徴とし、JSON エンコードされたリクエスト本文をサポートし、JSON エンコードおよび XML エンコードされたレスポンスを返し、標準の HTTP メソッド、認証、レスポンスコードに準拠しています。
Dynadot APIは、テストモードと本番モードの両方で使用できます。モードは、リクエストの認証に使用するAPIキーによって決まります。テストモードでは、実際のデータやトランザクションに影響を与えずに、API連携をシミュレートして検証できます。
Dynadot API は主にドメイン管理, 注文処理, および関連サービスに重点を置いています. ドメインの登録, 移管, 更新, DNS 設定の管理, アカウントの注文の表示や更新などの操作を行えます.
ご注意ください: 一括作成、更新、削除はサポートされていません。また、これらのリクエストタイプはそれぞれ1つのオブジェクトまたはアクションに制限されています。
APIリクエストを開始する前に, APIキーとAPIシークレットを生成することが必須です.
これらのキーは認証に必要で当社のAPIと連携する際の操作の安全性を確保するためのものです.
アカウント設定のAPIセクションから、APIキーとAPIシークレットの両方を生成できます。
1. Dynadotでアカウントにログインしてください。
2. ツール > API に移動します。
3. このページでAPIキーとAPIシークレットを生成してください.
APIは、リソースに対して操作を実行するために標準的なHTTPメソッドを使用します:
| メソッド | 説明 |
|---|---|
| GET | GETリクエスト: 指定されたリソースの詳細情報を取得します |
| POST | POSTリクエスト: 新しいリソースを作成 |
| PUT | PUT リクエスト: 指定されたリソースを完全に更新します。 |
| DELETE | DELETEリクエスト: 指定されたリソースを削除します |
すべてのAPIリクエストのベースURLは次のとおりです:
https://api.dynadot.com/API リクエスト URL を構築する際は, メジャーバージョンだけを含めれば十分です. マイナーおよびパッチ更新は後方互換性を持つように設計されており既存のコードを壊すような変更は導入されません. これにより安定性が確保され実装を変更することなく段階的な改善や修正の恩恵を受けられます.
将来のバージョンがリリースされる際、古いバージョンに対する後方互換性を一定期間維持します。新機能および破壊的変更は、メジャーバージョンの更新で導入されます。
APIリクエストのヘッダーには、そのリクエストに関するメタデータが含まれています。このメタデータは、サーバーがリクエストを適切に処理するための重要なコンテキストを提供します。よく使用されるヘッダーには、次のものがあります:
リクエストボディで送信されるデータの形式を指定します。サーバーはこの情報を使用して、リクエストを正しく解析します。現在、受け入れ可能な値は application/json のみです。
クライアントが期待するレスポンス形式をサーバーに通知します.
可能な値: application/json, application/xml
すべてのAPIリクエストには、認証用のAPIキーを含める必要があります。APIキーはアカウントのダッシュボードから取得できます。
APIキーは、API設定ページで生成できます。X-Request-ID ヘッダーは、各 API リクエストを一意に識別するために使用される (オプション) ヘッダーです。含まれている場合、このヘッダーはシステムやログ全体でリクエストを追跡・関連付けるのに役立ち、API アクティビティのデバッグと監視を容易にします。
X-Request-ID の値は、標準形式 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx（例：123e4567-e89b-12d3-a456-426614174000）に従った、有効な UUID（汎用一意識別子）でなければなりません。
X-Signatureヘッダーは、機密情報の取得やデータ更新を含むトランザクションリクエストにおいて必須のセキュリティ機構です。クライアントがHMAC-SHA256を使ってリクエストペイロードに署名することを求めることで、APIリクエストの真正性、完全性、否認防止を確保します。
署名を生成するには,次の値が必要です
1. APIキー: あなた専用の API キーです。
2. フルパスとクエリ: APIエンドポイントの完全なパスとクエリパラメータ.
3. X-Request-Id: リクエストID。取得できない場合は、空文字列を入力できます。
4. リクエストボディ: リクエストの本文. 空またはnullの場合,空文字列を入力できます.
署名対象の文字列は上記の値の組み合わせであり, 次の順序で連結されます:
apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
apiKey = "your_api_key"
fullPathAndQuery = "/restful/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"
stringToSign = "your_api_key\n/restful/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"stringToSign を構築した後、HMAC-SHA256 を使用し、シークレット をキーとして署名を計算してから、結果を Base64エンコード します。
署名は次の手順で生成されます:
1. HMAC-SHA256アルゴリズムを使用します.
2. stringToSign (UTF-8) を入力メッセージとして使用します。
3. シークレット（UTF-8）をキーとして使用します。
4. HMAC出力をBase64 (標準Base64)でエンコードします
生成された 署名 を、リクエストヘッダーの X-Signature の値として設定します
import base64
import hashlib
import hmac
import uuid
def create_signature(api_key, api_secret, full_path_and_query, x_request_id, request_body=""):
string_to_sign = (
api_key + "\n" +
full_path_and_query + "\n" +
(x_request_id or "") + "\n" +
(request_body or "")
)
digest = hmac.new(
api_secret.encode("utf-8"),
string_to_sign.encode("utf-8"),
hashlib.sha256
).digest()
return base64.b64encode(digest).decode("utf-8")
api_key = "your_api_key"
api_secret = "your_secret"
full_path_and_query = "/restful/v2/accounts/info"
x_request_id = str(uuid.uuid4())
request_body = ""
x_signature = create_signature(
api_key,
api_secret,
full_path_and_query,
x_request_id,
request_body
)
print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)APIリクエストのボディはサーバーにデータを送信するために使用されます. これは通常POST, PUT, またはPATCHリクエストに含まれます (通常はGETやDELETEリクエストには含まれません).
ボディデータの形式は、Content-Typeヘッダーによって決まります。一般的な形式には次のものがあります:
POSTリクエスト: POSTメソッドはサーバー上に新しいリソースを作成するために使用されます. リクエストボディには通常リソースの詳細が含まれます..
PUTリクエスト: PUT メソッドは既存のリソースを完全に置き換えて更新するために使用されます. リクエストボディには更新後の完全なリソースが含まれます.
DELETEリクエスト: DELETE メソッドは、サーバーから既存のリソースを削除するために使用されます。 リクエストボディはありません。
GETリクエスト: GETメソッドは、サーバーから既存のリソースを取得するために使用されます。 リクエストボディはありません
すべてのAPIレスポンスはJSONまたはXML形式で返されます。ボディデータの形式はAcceptヘッダーによって決まり、該当する場合は要求されたデータまたはエラーメッセージを提供します。
通常、レスポンスには3つの部分が含まれます: Code、Message、Data
コード: リクエストのステータス
メッセージ: ステータスのより詳しい説明
データ: レスポンスのボディ
HTTPステータスコードは、クライアントのリクエストの結果を示すためにサーバーから返される標準化された3桁の数字です。リクエストが正常に処理されたか、追加のアクションが必要か、エラーが発生したかについての重要な情報を提供します。これらのコードは5つのカテゴリに分かれており、それぞれが異なるタイプの応答を表します。
当社のAPIのステータスコードは、一貫性と信頼性の高い通信を保証する広く受け入れられた標準であるHTTP/1.1プロトコルに準拠しています。HTTP/1.1を使用することで、永続接続や拡張キャッシュなどの機能を活用し、クライアントとサーバー間のやり取りを最適化します。
Webhookは、プロセスの自動化やシステム連携に役立つ強力なツールです。アカウントやドメイン設定のイベントや変更に関するリアルタイム通知を受け取ることができます。Webhookを設定すると、外部システムでアクションを実行したり、データベースを更新したり、特定のイベントに基づいて通知を送信したりできます。
Dynadot APIは,ドメイン登録,移管,更新,期限切れなどのさまざまなイベントのWebhook通知をサポートしているため,それに応じて適切なアクションを実行できます.
Webhookを使用するには、通知の送信先となるURLエンドポイントを指定する必要があります。WebhookのURL、キー、シークレットはアカウント設定で構成できます。イベントが発生すると、Dynadotは関連データを含むPOSTリクエストを指定されたURLに送信します。
Webhookリクエストのヘッダーには、リクエストに関するメタデータが含まれます。このメタデータは、サーバーがリクエストを適切に処理するための重要なコンテキストを提供します。よく使用されるヘッダーには、次のものがあります:
リクエストボディで送信されるデータの形式を指定します。サーバーはこの情報を使用して、リクエストを正しく解析します。現在、受け入れ可能な値は application/json のみです。
すべてのWebhookリクエストには認証用のWebhookキーが含まれます。Webhookキーはアカウントダッシュボードから取得できます。
WEBHOOK_KEY は API 設定ページで管理できますX-Signatureヘッダーは、機密情報の取得やデータ更新を含むトランザクションリクエストにおいて必須のセキュリティ機構です。クライアントがHMAC-SHA256を使ってリクエストペイロードに署名することを求めることで、Webhookリクエストの真正性、完全性、否認防止を確保します。
署名を生成するには,次の値が必要です
1. WEBHOOKキー: あなた専用のWEBHOOKキーです。
2. フルパスとクエリ: クエリパラメータを含むWEBHOOKエンドポイントの完全なパス。
3. X-Request-Id: リクエストID。取得できない場合は、空文字列を入力できます。
4. リクエストボディ: リクエストの本文. 空またはnullの場合,空文字列を入力できます.
署名対象の文字列は上記の値の組み合わせであり, 次の順序で連結されます:
webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
webhookKey = "your_webhook_key"
fullPathAndQuery = "/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"
stringToSign = "your_webhook_key\n/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"stringToSign を構築した後、HMAC-SHA256 を使用し、シークレット をキーとして署名を計算してから、結果を Base64エンコード します。
署名は次の手順で生成されます:
1. HMAC-SHA256アルゴリズムを使用します.
2. stringToSign (UTF-8) を入力メッセージとして使用します。
3. シークレット（UTF-8）をキーとして使用します。
4. HMAC出力をBase64 (標準Base64)でエンコードします
生成された 署名 を、リクエストヘッダーの X-Signature の値として設定します
import base64
import hashlib
import hmac
import uuid
def create_signature(webhook_key, webhook_secret, full_path_and_query, x_request_id, request_body=""):
string_to_sign = (
webhook_key + "\n" +
full_path_and_query + "\n" +
(x_request_id or "") + "\n" +
(request_body or "")
)
digest = hmac.new(
webhook_secret.encode("utf-8"),
string_to_sign.encode("utf-8"),
hashlib.sha256
).digest()
return base64.b64encode(digest).decode("utf-8")
webhook_key = "your_webhook_key"
webhook_secret = "your_secret"
full_path_and_query = "/v2/some/webhook/path"
x_request_id = str(uuid.uuid4())
request_body = ""
x_signature = create_signature(
webhook_key,
webhook_secret,
full_path_and_query,
x_request_id,
request_body
)
print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)Webhookリクエストの本文には通知をトリガーしたイベントに関する情報が含まれています. 本文データの形式はContent-Typeヘッダー, 通常はapplication/jsonです.
リクエストの本文には次のパラメータが含まれます:
例：
リクエストのボディには、以下のパラメータが含まれます:
| パラメータ | 説明 |
|---|---|
| イベント | 通知のきっかけとなったイベントの種類. |
| event_id | 通知をトリガーしたイベントのID. |
| タイムスタンプ | イベントが発生した時点のタイムスタンプ。 |
| データ | イベントに関連するデータ。 |
webhookリクエストへの応答は、リクエストで指定されたContent-Typeヘッダーに応じて、JSON形式で送信されます。
レスポンスボディには、リクエストのステータスに関する情報が含まれます。たとえば、正常に処理されたか、エラーが発生したかなどです。
一般的にレスポンスには 1 つの部分が含まれます: Status
例：
セキュリティのためリクエストは https (セキュアソケット) 経由で送信してください. 同時に処理できるリクエストは 1 件だけなので, 次のリクエストを送る前に現在のリクエストが完了するのをお待ちください.
アカウントの料金レベルに応じて、異なるスレッド数が提供されます：
| 価格レベル | スレッド数 | レート制限 |
|---|---|---|
| 通常 | 1スレッド | 60/分 (1/秒) |
| バルク | 5スレッド | 600/分 (10/秒) |
| スーパーバルク | 35スレッド | 6000/分 (100/秒) |
注: place_auction_bid & get_auction_bid は現在、上記のレート制限の対象外です。
ドメイン査定コマンド, アカウントの価格レベルに基づいて許可されるリクエスト数が異なります:
| 価格レベル | レート制限 |
|---|---|
| 通常 | 50/日 |
| バルク | 100/日 |
| スーパーバルク | 300/日 |
Dynadot APIサンドボックス環境では本番アカウントや実際の資金に影響を与えることなくAPI統合を安全にテストできます.
1. Dynadotアカウントにログインし、API設定ページに移動します:
2. https://www.dynadot.com/account/domain/setting/api.html
3. APIサンドボックスキーとAPIサンドボックスシークレットキーを生成します。
4. 生成後、システムがサンドボックスキーを有効化し、サンドボックスアカウントを作成するまで、しばらくお待ちください。
5. Sandbox アカウントにはテスト目的で対応しているすべての通貨で 10,000 の残高が事前に付与されます.
サンドボックス環境のAPIコマンドは、本番環境と機能的に同じです。
唯一の違いはベースURLです:
本番API URL: https://api.dynadot.com
サンドボックスAPI URL: https://api-sandbox.dynadot.com
一部の API コマンドは Sandbox 環境で利用できない場合があります. "APIサンドボックスをサポート" ラベルを確認するには該当するコマンドのドキュメントを参照してください.
サンドボックスは主にテスト用に設計されています。一部のコマンドは本番環境と異なる場合があり、本番環境にあるサンドボックスの すべての可能な複雑なシナリオを完全にシミュレートすることはできません。
変更履歴は、APIの各バージョンで導入された変更、改善、バグ修正、新機能を詳細に記録したものです。各更新の影響を文書化することで、ユーザーと開発者に透明性を提供します。これは2つの主要な部分で構成されています:
この部分では API のバージョン管理システムに焦点を当てています。これは開発者が機能の進化を追跡し、互換性を確保するのに役立ちます。各 API バージョンは一意のバージョン番号（例: v1.0.1、v2.2.3）で識別され、重要なマイルストーンまたはリリースを表します。バージョン管理により、ユーザーは準備ができたときに更新を選択することで、最小限の中断で統合を維持できます。
変更履歴では、各バージョンで導入された更新、バグ修正、非推奨化、および機能強化に関する詳細情報を提供します。エンドポイント、パラメータ、認証メカニズム、またはレスポンス形式に行われた具体的な変更を概説します。このセクションにより、開発者は何が変更されたかについて完全な透明性を確保でき、実装をそれに応じて調整できます。明確で詳細な変更ログを維持することで、開発者が統合を効果的かつ自信を持って管理するために必要なツールと情報を提供することを目指しています。
バージョンコードはAPIの更新を体系的に識別および管理するために使用されます. それらはセマンティックバージョニング(SemVer)形式に従います:
バージョンコードの各コンポーネントは特定の目的を果たし、開発者が変更の範囲と種類を効果的に伝えるのに役立ちます。
定義: 後方互換性を損なう可能性のある重大な変更を表します。
形式:
x.<Minor>.x定義: 後方互換性のある機能追加を示します。
形式:
x.<Minor>.x定義: 後方互換性のあるバグ修正または軽微な改善を指します。
形式:
x.x.<Patch>変更履歴はソフトウェアやAPIの各バージョンで導入された変更, 改善, バグ修正, 新機能の詳細な記録です. 各更新の影響を文書化することでユーザーと開発者に透明性を提供します.
変更ログの一般的な項目には、以下が含まれます:
説明: 何が変更されたかの簡単な説明。
影響を受けるコンポーネント: 変更の影響を受ける特定のモジュール、エンドポイント、または機能。
Dynadot APIのすべての変更を追跡できます。