Skip to main content
Back to Use cases

Platform automation (for operators)

Let platform engineers and automation manage your API platform with the same sign-on and permissions as the admin UI. One auth model for both.

Practical use cases

Concrete ways teams use Zerq for this scenario.

  • Create a new API product or proxy from a script or CI/CD

    Your pipeline or script calls the management API (via MCP or REST) to create a collection, add a proxy, or update a workflow. Same credentials as the admin UI; every change is audited. Ideal for promoting config from dev to prod or onboarding new products per environment.

  • Let an AI assistant create or update workflows from natural language

    An AI tool in your IDE or chat can create a collection, add endpoints to a proxy, or modify a workflow from a request like “Add a new product for Partner X with rate limit 1000/min.” The assistant uses the same identity and permissions as a human admin—one audit trail.

  • One audit trail for UI and automation

    Every change made via the management API—whether from the admin UI, a script, or an AI agent—shows up in the same audit log. Compliance and ops see who changed what and when, without distinguishing human vs automation.

Outcomes

  • Platform engineers and automation manage collections, proxies, and workflows with the same permissions as the admin UI.
  • One auth model for both human operators (UI) and automation; no duplicate credentials or policy.
  • Single audit trail for configuration changes whether made in the UI or via automation.

How Zerq helps

  • Management MCP endpoint uses the same management auth (OIDC + RBAC) as the admin UI; no separate MCP identity or key management.
  • MCP handler forwards tool calls to the management API; RBAC is enforced by the API (viewer vs modifier roles).
  • Tools mirror the management API: collections (list, get, get_proxies, create, update, delete, toggle_collection_status), proxies (list, get, create, update, delete), workflow (list_nodes, list_templates, test_node, get_proxy_workflow, update_proxy_workflow, validate).
  • Optional well-known OAuth protected resource (RFC 9728) for discovery; MCP clients use your existing identity provider to obtain tokens.
  • Full audit: management API (and thus MCP tool calls) is audited like any other management action.
For architects & evaluators (technical context, requirements)

Technical context

Teams want to automate API platform operations—creating and updating collections, proxies, and workflows—using scripts, CI/CD, or AI-assisted tooling. Doing this via the same identity and permissions as the admin UI avoids separate service accounts and keeps a single audit trail. The Model Context Protocol (MCP) provides a standard way for clients to discover and invoke tools. Exposing the management API as MCP tools, with the same OIDC token and role-based access (viewer, modifier, etc.), means one identity provider, one RBAC model, and one place to audit who changed what.

Technical requirements

  • Manage collections and proxies via a standard protocol (e.g. MCP) with the same auth as the admin UI.
  • OIDC and RBAC: viewers can list and get; modifiers can create, update, delete; no separate MCP-only credentials.
  • MCP tools for collections (list, get, create, update, delete, toggle status), proxies (list, get, create, update, delete), and workflows (get, update, validate, list nodes/templates).
  • Optional OAuth discovery (e.g. RFC 9728 well-known) so MCP clients can discover the protected resource and obtain tokens from the organization's identity provider.

Request Enterprise Demo