Introducing the Zenmanage Management API

If you have been managing flags by clicking through the dashboard, that still works fine. But it does not work for a CI pipeline that needs to create a flag as part of a deploy, a GitOps process that wants flag state checked into a repo, or a script that ramps a rollout percentage on a schedule. Up to now, the only programmatic surface was the evaluation API — built for SDKs to read flag values, not for tooling to change them. There was no way to script a flag change without going through the UI.

The Management API closes that gap. It is a separate, versioned REST API for configuration — distinct from the evaluation API your SDKs already call.

Full CRUD over flags, targets, and rules

Everything you can do in the dashboard, you can now do over HTTP: create and update flags, publish targets, adjust rollout percentages, and manage targeting rules. Creating a flag looks like this:

curl -X POST https://api.zenmanage.com/management/v1/projects/your-project/flags \
  -H "Authorization: Bearer mgt_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "new-checkout",
    "name": "New Checkout",
    "type": "boolean",
    "description": "Rolls out the redesigned checkout flow."
  }'

Rolling a flag out to a percentage of traffic is a draft-then-publish flow: start a draft target, attach a rollout, then publish it.

curl -X POST https://api.zenmanage.com/management/v1/projects/your-project/flags/new-checkout/environments/staging/targets \
  -H "Authorization: Bearer mgt_your_token_here"

curl -X POST https://api.zenmanage.com/management/v1/projects/your-project/flags/new-checkout/environments/staging/targets/{targetUlid}/rollout \
  -H "Authorization: Bearer mgt_your_token_here" \
  -d '{"rollout_mode": "manual", "rollout_percentage": 10}'

curl -X PUT https://api.zenmanage.com/management/v1/projects/your-project/flags/new-checkout/environments/staging/targets/{targetUlid}/publish \
  -H "Authorization: Bearer mgt_your_token_here" \
  -d '{"comment": "Rolling out to 10% of staging."}'

Targeting rules — the same country/plan/attribute criteria you would set up in the dashboard — are managed the same way, appended, reordered, or replaced with a single request. This is enough surface to do everything short of clicking around.

Scoped tokens, not one big secret

A CI job that only needs to flip flags in staging should not be holding a credential that can also touch production targeting rules. Management API tokens are scoped: flags:read, flags:write, targets:read, targets:write, projects:read, and audit:read. A token missing the scope an endpoint needs gets a 403, not a partial success. Tokens are shown once, stored hashed, and can be revoked the moment you no longer trust them.

Every call the token makes — reads, writes, and denied attempts alike — lands in your account's audit log, alongside the actor, the HTTP method and path, and the result. You can pull that log through the API too, so "what changed in production last night, and who has been calling this token" is a query, not a support ticket.

Built to be called from a script, not just a browser

A write API that automation depends on has to behave predictably under retries and load. Every token is rate limited per minute, with X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on every response, and a 429 with Retry-After when you go over. And any POST or PUT accepts an Idempotency-Key header — replay the same key with the same body and you get the original response back instead of a duplicate flag or a second rollout step:

curl -X POST https://api.zenmanage.com/management/v1/projects/your-project/flags \
  -H "Authorization: Bearer mgt_your_token_here" \
  -H "Idempotency-Key: deploy-2026-08-31-new-checkout" \
  -d '{"key": "new-checkout", "name": "New Checkout", "type": "boolean"}'

That matters most in the exact place automation tends to fail: a deploy script that retries a timed-out request. Without idempotency keys, that retry either double-creates a flag or double-steps a rollout. With one, it just gets the same answer back.

Webhooks fire on management changes too

If you already have a webhook configured on an environment, it now fires on changes made through the Management API the same way it fires on changes made through the dashboard — flag.target.changed, target.rule.created, target.rule.changed, and target.rule.removed. If your pipeline scripts a rollout, your existing cache-invalidation or Slack-notification webhook does not need to know or care whether the change came from a person or a script.

An OpenAPI spec and a Swagger UI to try it live

The full API is published as an OpenAPI v3 document at api.zenmanage.com/management/v1/api-docs — use it for client generation or schema validation. If you would rather poke at it before writing any code, the Swagger UI explorer opens with the Management API selected: drop in a Bearer token and try requests against real endpoints, no client setup required.

Where this fits: CI/CD and GitOps

This is the use case the API was built around. A deploy pipeline that creates a flag as part of shipping new code. A promotion job that ramps a rollout percentage after a canary period, scripted with an idempotency key so a retried step never double-ramps. A GitOps setup that diffs desired flag state against a YAML file and reconciles it through the API on merge. None of that requires a human in the dashboard, and all of it shows up in the audit log with the token that did it.

Getting started

Create a management API token from your account settings, pick the scopes it needs, and start making requests against https://api.zenmanage.com/management/v1. The Management API reference has the full endpoint list, request/response examples, and error envelope. The webhooks reference covers event types and payload shape if you want to wire up a consumer.