WordPress開発者がサイト操作やDNS設定、リソース設定をより細かく管理できるようにするため、APIエンドポイントの新機能と機能強化を公開しました。
WordPressサイトのリセットから、ドメイン検証レコードやDNSエントリの管理まで、大規模な作業も自動化できるようになっています。
新機能は次のとおりです。
サイトのリセット
MyKinsta管理画面と同様に、APIの新しい/reset-site
エンドポイントを使ってWordPressサイトをリセットできるようになりました。この操作は、サイトのファイルシステムとデータベースを初期化し、クリーンなWordPressインストール状態に戻します。
スクリプトによるセットアップ、テンプレートのプロビジョニング、開発中の迅速な再スタートなどに最適です。
使用するにはサイトIDと管理者パスワードを指定しPOST
リクエストを送信します。
curl -i -X POST \
'https://api.kinsta.com/v2/sites/{site_id}/reset-site' \
-H 'Authorization: Bearer ' \
-H 'Content-Type: application/json' \
-d '{
"admin_password": "your-admin-password"
}'
ドメインの所有権確認レコードと紐付けレコードの取得
/verification-records
エンドポイントを新たに追加し、WordPress環境に紐づくすべてのドメインについて、所有権確認のレコードと紐付けのレコードを取得できるようになりました。
これは、カスタムドメインを設定し、正しく紐付けられているか確認する際に役立ちます。また、CI/CDやプロビジョニングワークフローの一部としてドメイン検証を自動化したい場合にも有効です。
リクエストの例は以下の通りです。
curl -i -X GET \
'https://api.kinsta.com/v2/sites/environments/domains/{site_domain_id}/verification-records' \
-H 'Authorization: Bearer '
レスポンスには、ドメインの検証やエッジネットワーク設定に必要なCNAME
やTXT
などのDNS関連レコードが含まれます。
{
"site_domain": {
"verification_records": [
{
"name": "_acme-challenge.staging.example-site.io",
"value": "staging.example-site.io.kinstavalidation.app",
"type": "CNAME"
}
],
"pointing_records": [
{
"name": "staging.example-site.io",
"value": "192.0.2.10",
"type": "A"
},
{
"name": "www",
"value": "staging.example-site.io",
"type": "CNAME"
}
]
}
}
プログラムによるDNSレコードの管理
Kinsta APIを使って、ドメインやDNSレコードをプログラムで管理できるようになりました(MyKinstaの「Kinsta DNS」内で利用できる機能と同様)。
これには次の操作が含まれます。
- 会社のドメイン一覧の取得
- ドメインのDNSレコードの取得
- A、AAAA、CNAME、MX、TXT、CAA、SRVなどのレコード作成
- リソース値やTTLを変更してDNSレコードを更新
- ドメインゾーンからレコードを削除
このAPIは、Amazon Route53を利用したKinsta DNSに紐づくゾーンを管理する際にMyKinstaで行える操作と同じ内容を反映しています。
例えば、サブドメインにA
レコードを追加する場合は次のとおりです。
curl -X POST \
'https://api.kinsta.com/v2/domains/{domain_id}/dns-records' \
-H 'Authorization: Bearer ' \
-H 'Content-Type: application/json' \
-d '{
"type": "A",
"name": "staging.mydomain.com",
"ttl": 3600,
"resource_records": [
{ "value": "1.1.1.1" }
]
}'
これは、ドメインを動的にプロビジョニングする場合や、CI/CDパイプラインでDNSの変更を同期する場合、特にマルチサイトを扱うWeb制作会社やステージング環境が多いワークフローで有効です。
対応するレコードタイプやDNSの仕様については、Kinsta DNSドキュメントを参照してください。
PHPスレッド割り当ての設定
PHPパフォーマンスアドオンは、Kinstaで最も利用されているアドオンの1つで、サイトが負荷をかけずに多くのトラフィックや重い処理を処理できるようにします。
このコントロールをAPIから利用できるようにするのは自然な流れであり、今年初めにはプログラム経由でPHPパフォーマンスを管理できる2つのエンドポイントを追加しました。
これらのエンドポイントは当初worker_number
とworker_memory
を受け付けていましたが、全社的な変更により、「ワーカープロセス」からPHPの実際の動作をより正確に反映した「スレッド」への呼び方に切り替えたため、これらの旧フィールドは現在非推奨となっています。

2025年8月末までにサポートされるのはthread_count
とthread_memory
のみです。これらのエンドポイントをすでに利用している場合は、今のうちにリクエストを更新してください。
更新後のフィールドを使ったスレッド設定リクエストは以下のとおりです。
curl -i -X POST \
'https://api.kinsta.com/v2/sites/environments/{env_id}/change-environment-php-allocation' \
-H 'Authorization: Bearer ' \
-H 'Content-Type: application/json' \
-d '{
"thread_count": 2,
"thread_memory": 256
}'
この例では、その環境に2つのPHPスレッドを割り当て、それぞれ256MBのメモリを使用します。MyKinstaのコントロールと同じ内容です。
環境リストにWordPressのバージョン表示を追加
複数サイトを管理している場合、各環境のWordPressバージョンを正確に把握できると便利です。特に、チームごとにクライアントやステージ間で更新スケジュールが異なるケースに役立ちます。
以下のエンドポイントに新しいフィールドwordpress_version
を追加しました。
これにより、環境データを取得する際にWordPressバージョンが含まれるようになり、各サイトに手動でログインせずに古いインストールを特定したり、アップデートが正しく反映されているかを確認しやすくなります。
レスポンスの例は以下の通りです。
{
"site": {
"environments": [
{
"id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
"name": "live",
"display_name": "Live",
"wordpress_version": "6.3.1",
"is_premium": false,
"is_additional_sftp_accounts_enabled": false,
...
}
]
}
}
利用可能なリージョンの取得
特定の地域で新しい環境を構築する必要がある場合、新しい/available-regions
エンドポイントで、会社に紐づく利用可能なリージョン一覧を取得できます。
これにより、デプロイ可能なデータセンターの場所を遠隔で確認でき、複数クライアントの管理や異なる地域でのスケーリングに有用です。
レスポンスの例は以下の通りです。
{
"company": {
"available_regions": [
{
"name": "Dallas US (us-south1)",
"region": "us-south1"
}
]
}
}
ワークフローをより柔軟に
この一連のアップデートにより、環境、ドメイン、DNSレコード、PHPパフォーマンス、および地域的なデプロイメントを柔軟に制御できるようになります。
スレッドとメモリの微調整、スケールでのドメイン管理、サイト間でのWordPressバージョンの同期など、Kinsta APIは最新の技術を念頭に置いて成長を続けています。
スケールの実績として、SodがKinsta APIを使ったカスタムオートメーションで400以上のサイトを管理している事例を公開しました。