# Reset sites, manage DNS records, and more with Kinsta API **URL:** https://community.kinsta.com/t/reset-sites-manage-dns-records-and-more-with-kinsta-api/5343 **Category:** News and Announcements **Created:** [August 1, 2025, 10:13am UTC](https://community.kinsta.com/t/reset-sites-manage-dns-records-and-more-with-kinsta-api/5343 "2025-08-01T10:13:40Z") **Posts on this page:** 1 **Page:** 1
### Author: ![jeff](https://sea2.discourse-cdn.com/flex020/user_avatar/community.kinsta.com/jeff/32/16_2.png) [@jeff](https://community.kinsta.com/u/jeff) #### Post date: [August 1, 2025, 10:13am UTC](https://community.kinsta.com/t/reset-sites-manage-dns-records-and-more-with-kinsta-api/5343/1 "2025-08-01T10:13:40Z")
We’ve rolled out a new set of [API](https://api-docs.kinsta.com/) endpoints and enhancements focused on giving WordPress developers more control over site operations, DNS configuration, and resource settings. You can now automate tasks ranging from resetting WordPress sites to managing domain verification records and DNS entries, especially at scale. ### Info You need a valid API key to use Kinsta API endpoints. You can [create or manage your API keys](https://kinsta.com/blog/kinsta-api-key/) in MyKinsta. Here’s what’s new: ## Reset a site As with the [MyKinsta](https://kinsta.com/mykinsta/) dashboard, you can now reset a WordPress site using the API’s new `/reset-site` endpoint. This action resets the site’s file system and database, restoring it to a clean WordPress installation. This is ideal for scripted setups, provisioning templates, or quickly starting fresh during development. To use it, send a `POST` request with the site ID and your **admin password** : ``` 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" }' ``` ### Important This action is irreversible and should be used with caution, just like with MyKinsta. It’s especially useful when spinning up demo sites, running staging refreshes, or automating teardown setups. ## Fetch verification and pointing records for a domain We have also introduced the `/verification-records` endpoint, which allows you to fetch both verification and pointing records for any domain connected to a WordPress environment. This is helpful when setting up custom domains and confirming they’re pointing correctly. It’s also helpful if you want to automate domain verification as part of [CI/CD](https://kinsta.com/blog/how-to-setup-ci-cd-pipeline/) or provisioning workflows. Here’s an example request: ``` curl -i -X GET \ 'https://api.kinsta.com/v2/sites/environments/domains/{site_domain_id}/verification-records' \ -H 'Authorization: Bearer ' ``` The response includes DNS-related records like `CNAME` or `TXT` entries needed for domain validation and edge network configuration: ``` { "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" } ] } } ``` ## Manage DNS records programmatically You can now programmatically manage domains and [DNS](https://kinsta.com/knowledgebase/what-is-dns/) records using the Kinsta API (similar to the functionality available in MyKinsta under Kinsta’s DNS). This includes: - [Listing domains for a company](https://api-docs.kinsta.com/tag/Domains#operation/getDomains) - [Retrieving DNS records for a domain](https://api-docs.kinsta.com/tag/Domains#operation/getDomains) - [Creating records](https://api-docs.kinsta.com/tag/Domains#operation/createDomainDnsRecord), including A, AAAA, CNAME, MX, TXT, CAA, SRV, and more - [Updating DNS records](https://api-docs.kinsta.com/tag/Domains#operation/updateDomainDnsRecord) by modifying resource values or TTLs - [Deleting records](https://api-docs.kinsta.com/tag/Domains#operation/deleteDomainDnsRecord) from a domain zone This API support mirrors what you can do in MyKinsta when managing zones linked to Kinsta’s DNS, powered by Amazon Route53. For instance, if you want to add an A record for a subdomain, here’s how you’d do it: ``` 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" } ] }' ``` This is useful when provisioning domains dynamically or syncing DNS changes from your CI/CD pipeline, especially for multisite agencies or staging-heavy workflows. For supported record types and DNS behavior, refer to [Kinsta’s DNS docs](https://kinsta.com/docs/wordpress-hosting/wordpress-domains/dns/#how-to-add-dns-records). ## Set PHP thread allocation The [PHP performance add-on](https://kinsta.com/docs/wordpress-hosting/php/wordpress-php-performance/) is one of the most used add-ons at Kinsta, as it helps sites handle more traffic and heavy processing without breaking a sweat. It made sense to bring that control into the API, and so earlier this year, we introduced two endpoints to manage PHP performance programmatically: - [Change PHP allocation for premium staging environments](https://api-docs.kinsta.com/tag/WordPress-Site-Environments#operation/changeEnvironmentPhpAllocation) - [Change PHP allocation for live and standard staging environments](https://api-docs.kinsta.com/tag/WordPress-Site-Environments#operation/changeSitePhpAllocation) These endpoints originally accepted `worker_number` and `worker_memory`, but in line with our [company-wide switch](https://kinsta.com/changelog/workers-now-threads/) from “PHP workers” to “threads” (which better reflects how PHP actually works), we’ve now deprecated those old fields. ![Deprecated PHP fields](https://us1.discourse-cdn.com/flex020/uploads/kinsta/original/2X/9/9b6d3f72a37e36adb3d2d7a5734826a1f7d65941.png)Deprecated fields. By the end of August 2025, only `thread_count` and `thread_memory` will be supported. If you’re using these endpoints already, now’s the time to update your requests. Here’s what a thread configuration request looks like using the updated fields: ``` 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 }' ``` The above sets two PHP threads for that environment, each with 256MB of memory. This matches the same control you find in MyKinsta. ### Important Thread and memory allocation directly impact site performance and stability. If you’re unsure how to configure them, we recommend reviewing [PHP Performance in the Kinsta Docs](https://kinsta.com/docs/wordpress-hosting/php/wordpress-php-performance/) before making changes. This is especially important for WooCommerce sites, high-traffic campaigns, or environments with custom plugins. ## Environment listings now show WordPress version When managing multiple sites, it’s helpful to know exactly which version of WordPress each environment is running, especially if your team has different update schedules across clients or stages. We’ve added a new `wordpress_version` field to these endpoints: - [Get site environments](https://api-docs.kinsta.com/tag/WordPress-Site-Environments#operation/getSiteEnvironments) - [Get a list of company sites](https://api-docs.kinsta.com/tag/WordPress-Sites#operation/getSites) Now, when you fetch environment data, the WordPress version is included. This makes it easier to spot outdated installs or confirm updates were applied successfully without manually logging into each site. Here’s an example of what the response looks like: ``` { "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, ... } ] } } ``` ## Get a list of available regions Let’s say you need to spin up new environments in a specific location. With the new `/available-regions` endpoint, you can now retrieve the list of available regions tied to your company. This helps you programmatically confirm which data center locations are available for deployments and is useful if you’re managing multiple clients or scaling across different regions. Here’s a sample response: ``` { "company": { "available_regions": [ { "name": "Dallas US (us-south1)", "region": "us-south1" } ] } } ``` ## More flexibility for your workflows This batch of updates gives you more programmatic control over environments, domains, DNS records, PHP performance, and regional deployments. Whether you’re fine-tuning threads and memory, managing domains at scale, or syncing WordPress versions across sites, the Kinsta API continues to grow with modern teams in mind. Do you need proof that it scales? We recently published a case study on how [Sod manages 400+ sites](https://kinsta.com/clients/sod/) with custom automation built on the Kinsta API. The post [Reset sites, manage DNS records, and more with Kinsta API](https://kinsta.com/changelog/kinsta-api-jul-2025/) appeared first on [Kinsta®](https://kinsta.com). * * * This is a companion discussion topic for the original entry at [https://kinsta.com/changelog/kinsta-api-jul-2025/](https://kinsta.com/changelog/kinsta-api-jul-2025/)