We’ve rolled out a new set of API 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.

Here’s what’s new:

Reset a site

As with the 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"
  }'

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 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 records using the Kinsta API (similar to the functionality available in MyKinsta under Kinsta’s DNS).

This includes:

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.

Set PHP thread allocation

The PHP performance add-on 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:

These endpoints originally accepted worker_number and worker_memory, but in line with our company-wide switch from “PHP workers” to “threads” (which better reflects how PHP actually works), we’ve now deprecated those old fields.

Deprecated PHP fields
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.

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:

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 with custom automation built on the Kinsta API.