Skip to content

API overview

Preview The managed.dev public API is the programmatic surface for everything you can do in the dashboard — provision sites, push and promote environments, manage domains, read observability, and drive the dynamic application layer (plugins, themes, cron, content, the database) — through scoped tokens, a single versioned contract, and signed webhooks.

Most platforms force a choice. Generic PaaS — the gold standard for developer experience — give you scoped tokens, one spec that generates SDKs and a Terraform provider, signed webhooks, idempotency, and published limits, but they deliberately won’t manage your plugins, cron jobs, content, or database. Managed-WP hosts will touch that application layer, but only bluntly — a bulk plugin update, a raw WP-CLI pipe — behind coarse, often unscoped, tokens.

managed.dev is building the Managed.dev Forge Platform (Forge) — the first product-aware PaaS for managed CMS. PaaS-grade developer experience is the floor, not the differentiator:

  • Scoped tokens. Least-privilege API keys with per-resource, per-action scopes, TTLs, and revocation.
  • One spec → everything. A single OpenAPI 3.1 document generates the SDKs, the mf CLI, and the Terraform provider with a zero-drift release gate. See SDKs, CLI & tooling.
  • Signed webhooks, idempotency, versioning, published limits — the table-stakes reliability features you’d expect from a Stripe or a Cloudflare.

The differentiator sits on top of that floor: deep, fine-grained, capability-discovered control of the dynamic application layer (components, cron, database, content, exec) that generic PaaS won’t touch and WP hosts expose only crudely. The clearest, most concrete win over every WP host is authorization granularity — you mint a key that can update one plugin on one environment of one site, and nothing else.

The API is served at:

Base URL
https://api.managed.dev/v1

Versioning follows the Stripe model, split across two axes:

  • URL-major (/v1). Breaking shape changes — a removed field, a renamed resource, an incompatible payload — bump the URL major. Within /v1, new fields and endpoints are additive, so you should ignore unknown fields rather than fail on them.
  • Dated Forge-Version header. Breaking behavior changes are pinned with a dated header so your integration’s behavior is frozen to the date you built against:
Pin a behavior version
GET /v1/sites HTTP/1.1
Host: api.managed.dev
Authorization: Bearer mfk_live_…
Forge-Version: 2026-06-23

Every resource and endpoint also carries a stability tier in the spec — stable, beta, or experimental. Experimental surfaces may change within /v1; the SDKs surface the tier so you know what you’re depending on. See versioning for the full deprecation policy.

Resources

The endpoint reference, grouped by resource — sites, environments, deployments, domains, backups, observability, security, jobs, and the capability-gated application layer. Start at the resources overview.

Every authenticated call carries a bearer token and returns a consistent envelopedata plus a request_id you can quote in a support ticket:

List your sites
curl https://api.managed.dev/v1/sites \
-H "Authorization: Bearer mfk_live_…" \
-H "Forge-Version: 2026-06-23"
Response
{
"data": [
{
"id": "site_01J7ZC3W9Q8F2K7M3N0XB5R4D2",
"name": "acme-store",
"runtime": "wordpress",
"created_at": "2026-05-01T12:00:00Z"
}
],
"pagination": { "next_cursor": null, "has_more": false },
"request_id": "req_01J9F2K7M3N0XB5R4D2W9Q8F2K"
}

Mutations that aren’t instantaneous return a job you can poll or stream to completion — that pattern is the subject of the quickstart.