Hi Kinsta team,
We’re an agency running about 560 WordPress sites on Kinsta. We drive our day-to-day operations through the Kinsta API, with an MCP server our team and AI agents work with: troubleshooting, staging and pushes, migrations, plugin updates, redirects, fleet audits, suspensions and terminations. The API covers most of it, and the recent additions (search-and-replace, log windows, user roles, support_reference_id) helped a lot.
These six gaps are where we still send someone to MyKinsta, open a ticket, or make hundreds of calls. They’re ranked by how often they hit us:
- Complete plugin and theme inventory: pagination (limit/offset) and a filter (slug, version) on GET /company/{id}/wp-plugins and /wp-themes. Today they return 30 items of a larger total, so answering “which sites run plugin X below version Y” after a CVE takes over 1,000 calls.
- Environment suspension: POST /sites/environments/{env_id}/suspend and /activate, plus is_suspended on environments. A suspended environment currently reads status: live, so automation can’t see it.
- Cache rules: GET/PUT /sites/environments/{env_id}/cache-rules, for URL exclusions and query parameters ignored in the cache key (utm_*, gclid, fbclid). We set these on most launches.
- User management: invite a user, remove a user, and remove a user’s site access, to go with the new role endpoints. Offboarding is the step we most want automated and audited.
- Site labels: list all labels, and apply or remove one on a site.
- Downloadable backups: size and checksum (md5 or sha256) returned with download_link, and generation allowed on a suspended environment. Before deleting a site we archive it off-site, and we have to verify the copy against the checksum in the storage headers.
We’re happy to beta-test any of these on real sites and report back.
Thanks,
Alex Dignard
